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1.0  Introduction 

The  SCOUT  concept  was  derived  from  AeroAstro’s  Wooden  Round  Microsatellite 
(WoRM)  proposal  submitted  to  DARPA  in  December  of  2002.  WoRM  incorporated 
the  following  key  features: 

•  Multi-Mission  Compatibility  -  Tactical  communications;  Intelligence,  Surveillance  and 
Reconnaissance  (ISR);  or  weather  observation  are  all  possible  missions  for  a  WoRM. 

•  High  Payload  Mass  and  Power  Fractions  -  To  maximize  their  effectiveness,  the  majority  of  the  mass  of  a 
WoRM  must  be  payload.  We  will  aim  to  improve  on  the  traditional  30%  mass  fraction  by  at  least  30%, 
i.e.  achieve  a  payload  mass  fraction  of  60%.  Achieving  a  similarly  high  payload  power  fraction  is  equally 
important. 

•  Long  Shelf-Life  -  WoRMs  need  to  be  storable  for  several  months  or  years  in  the  field  with  limited 
or  no  maintenance,  much  like  an  ammunition  round. 

•  Rapid  Call-Up  for  Launch  -  As  with  any  modem  weapon,  the  WoRM  must  be  able  to  be  readied 
for  use  within  hours  by  skilled  military  personnel.  To  achieve  tactical  timelines,  the  WoRM  must 
require  the  minimum  possible  field  integration  and  have  built-in  test  equipment  (BITE). 

•  Rapid  Initialization  on  Orbit  -  The  tactical  advantage  of  a  WoRM  would  be  lost  if  check-out  and 
initialization  took  30-60  days  as  with  current  small  satellites.  WoRMs  must  initialize  on  ascent 
and  be  ready  to  perform  their  mission  on  their  first  orbital  pass. 

•  Manufacturability  -  WoRMs  will  be  built  in  substantially  higher  quantities  than  most  spacecraft.  While 
‘mass’  manufacturing  techniques  are  not  necessarily  applicable,  the  manufacturing  approaches  typical  of 
military  hardware  such  as  a  cruise  missile  are  much  more  relevant  than  those  used  on  large  complex 
military  spacecraft 

Based  upon  the  SCOUT  Kickoff  teleconference  with  Major  Shoemaker  on  02  DEC 
02,  AeroAstro  revisited  the  WoRM  concept  and  selected  its  best  elements  to  apply  to 
the  SCOUT  Phase  I  approach.  This  report  consolidates  the  results  of  that  effort. 

2.0  Mission  Definition 

The  initial  task  was  to  examine  a  broad  scope  of  missions  in  order  to  later  establish  a 
requirements  set  for  SCOUT.  From  there,  a  single  mission  was  selected  to  serve  as  an 
example  of  SCOUT's  capabilities,  and  a  detailed  mission  concept  for  it  was 
developed. 

Investigating  these  potential  SCOUT  missions  included  assessing  what  is  realistically 
and  technically  achievable,  and  investigating  the  corresponding  orbits,  launch 
vehicles,  and  encounter  scenarios.  The  various  missions  were  listed  out  and 
prioritized  based  on  DARPA's  expressed  interest  in  each  and  the  feasibility  of  each. 
The  mission  considered  to  be  maximally  useful  and  achievable  was  to  have  SCOUT 
equipped  with  the  ESCORT  payload,  monitoring  a  primary  spacecraft  in 
geosynchronous  orbit.  The  ESCORT  package  contains  the  AeroAstro  RF  Probe 
instrument  for  monitoring  RF  emanations;  a  COTS  visible  camera  and  a  COTS  laser 
range  finder. 

The  deliverable  for  this  task,  the  SCOUT  Mission  Definition  document  is  included  in 
Appendix  A  “Appendix  A  -  SCOUT_ Mission  Definition  FinaLdoc 


3.0  Technology  Assessment 

The  Technology  Assessment  task  included  identifying  the  key  technologies  necessary 
to  implement  the  SCOUT  architecture,  the  existing  and  projected  technologies 
available  to  satisfy  these  needs,  and  the  state  of  development  of  the  identified 
technologies.  In  cases  where  existing  technologies  were  not  expected  to  be 
sufficiently  mature,  AeroAstro  assessed  alternate  or  substitute  technologies. 

The  deliverable,  the  Technology  Utilization  and  Development  Plan  is  provided  in 
Appendix  B  {Appendix  B  -  SCOUT  Tech  Plan-Final,  doc). 

4.0  Launch  Vehicle  Compatibility  Analysis 

The  SCOUT  effort  proceeded  with  an  investigation  of  the  RASCAL  launch  vehicle 
and  the  development  of  a  set  of  requirements.  Other  available  launch  vehicles  were 
surveyed  and  requirements  developed.  Finally,  AeroAstro  developed  a  set  of  launch 
compatibility  requirements  for  SCOUT  that  enveloped  both  RASCAL  and  a  wide 
range  of  alternative  Launch  Vehicles. 

The  deliverable,  the  Technology  Utilization  and  Development  Plan  is  provided  in 
Appendix  C  ( Appendix  C  -  SCOUT LV-Finaldoc). 


5.0  Requirements  Definition 

Based  on  the  Launch  Vehicle  Compatibility  Document,  the  Concept  of  Operations, 
the  SCOUT  modularity  boundary  conditions  and  the  Escort  payload  and  mission, 
AeroAstro  developed  the  Escort-specific  mission  requirements  for  SCOUT. 

The  detailed  requirements  were  defined  for  each  subsystem. 

The  resulting  deliverable,  the  Mission  Requirements  Document,  is  provided  in 
Appendix  D  {Appendix  D  -  SCOUT  requirement  Matrix-Final.xls). 


6.0  SCOUT  Conceptual  Design 

The  requirements  provided  the  basis  for  the  SCOUT  Conceptual  Design.  AeroAstro 
developed  a  system  architecture  that  supported  the  Launch  Vehicle  and  mission 
requirements,  focusing  on  modular  approaches  to  the  spacecraft  bus  that  provided  for 
evolutionary  development  consistent  with  the  system  architecture.  AeroAstro 
identified  modules  common  to  multiple  missions  and  their  requirements  and 
identified  mission-specific  modules  and  their  requirements  consistent  with  the 
SCOUT  architecture.  Ongoing  technology  developments  were  identified  that  can  be 
leveraged  to  enable  or  improve  the  capabilities  of  SCOUT. 

The  deliverable,  the  Conceptual  Design  Review  of  the  mission  and  spacecraft,  is 
provided  in  a  collection  of  annotated  viewgraph  presentations  in  Appendix  E; 

•  00  Agenda  (Annotated).ppt 

•  01  Introduction  (Annotated1) .ppt 

•  02  Payload  (AnnotatedVppt 

•  03  Requirements  ( Annotatedi.ppt 

•  04  System  Overview  (Annotatedi.ppt 

•  05  Mech-Therm  (Annotatedi.ppt 

•  06  C&DH  (Annotated).ppt 

•  07  Software  (Annotatedhppt 

•  08  Power  (AnnotatedLppt 

•  09  ADCS  (AnnotatedVppt 

•  10  Propulsion  (AnnotatedVppt 

•  1 1  RF  Comm  f  Annotated). ppt 

•  12  Mission  Ops  ('AnnotatedVppt 

•  13  I&T  ( Annotated!. ppt 

7.0  Conclusion 

SCOUT  addresses  a  critical  need  for  rapidly  configurable  and  deployable  spacecraft.  It’s 
flexible  and  modular  architecture  will  offer  a  framework  for  many  applications  in  and 
outside  of  DARPA.  Successful  development  of  SCOUT  will  demonstrate  a  host  of 
technologies,  components  and  system  architectures  that  could  benefit  the  entire  microsat 
industry.  While  additional  work  is  needed,  the  conceptual  design  of  SCOUT  appears  to 
meet  the  immediate  objectives  of  the  effort. 
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1.0  SCOUT  Mission  Definition 

Per  section  2.0  of  the  Work  Breakdown  Structure,  an  investigation  of  potential  SCOUT  missions 
was  conducted  to  assess  what  is  realistically  and  technically  achievable  using  the  proposed 
SCOUT  architecture.  A  prioritized  list  of  missions,  based  upon  interest  and  feasibility,  was 
developed.  After  soliciting  input  from  the  DARPA  TPOC,  a  mission  down-select  was  conducted 
and  three  baselines  were  identified  to  be  carried  forward  into  conceptual  design. 

2.0  Identify  potential  top-level  mission  types 

To  define  and  envelope  the  scope  of  potential  applications  and  missions  for  SCOUT  in  either  a 
single  or  multi-element  deployment,  a  comprehensive  investigation  of  candidate  functions  and 
opportunities  was  conducted.  Based  upon  the  results  of  this  activity,  candidate  missions  were 
divided  into  top-level  categories  by  the  function  or  utility  to  be  provided  and  the  nature  of  the 
intended  role  of  the  SCOUT  vehicle(s).  Based  upon  this  scheme,  the  following  six  mission  types 
were  delineated: 

•  Satellite  inspection  and  logistics  services 

•  Near-field  situational  awareness  for  US  space  assets 

•  Extend  existing  space  and  terrestrial-based  capabilities 

•  Asset  protection 

•  Surveillance,  reconnaissance,  and  tactical  operations 

•  Rapid  access  and  flight  qualification  of  new  technologies 

The  subsequent  sections  will  address  the  specific  activities,  applications,  and  components 
associated  with  each  candidate  mission  genre. 

2.1.  Satellite  Inspection  &  Logistics  Services 

A  SCOUT  or  multiple  SCOUT  vehicles 
could  be  utilized  for  inspection  services 
of  a  friendly  target  satellite  to  aid  in 
deployments,  monitor  performance, 
and/or  investigate  anomalies. 

2.1.1.  Facilitate  In-Orbit  Test 

With  a  suitable  payload  sensor-suite 
that  could  include  an  Aero  Astro  RF 
Probe,  a  SCOUT  could  enable  analysis 
of  antenna  gain  patterns  including 
primary  and  side-lobes.  In  addition,  as  a 
maneuverable  point-source,  SCOUT 
could  also  assist  in  multispectral  and 
hyper-spectral  imager  calibration. 


2. 1.2.  Anomaly  Investigation  and  Resolution 

Employing  a  diagnostic  payload  that  might  include  such  components  as  the  AeroAstro  RF  Probe 
or  imaging  devices  (visible  or  infrared),  SCOUT  could  assist  in  the  investigation  and  resolution 
of  on-orbit  anomalies.  In  addition,  for  deployments  (solar  arrays,  antennas,  etc.)  that  are 
inhibited  or  not  fully  actuated,  SCOUT  may  be  utilized  to  mechanically  or  thermally  assist. 

2. 1.3.  Supply  Surrogate  or  Complementary  Functional  Element  or  Capability 

In  situations  where,  for  example,  an  uplink  receiver  of  a  space  asset  has  been  damaged  or  is 
otherwise  unable  to  maintain  sufficient  link  with  the  ground,  a  SCOUT  vehicle  may  be  used  as  a 
surrogate  for  communications  of  low  bandwidth  TT&C.  Additionally,  a  SCOUT  equipped  with 
sensors  could  be  used  to  complement  the  sensors  of  the  primary  space  asset,  including  supplying 
alternate  or  additional  attitude  determination  measurements  to  the  primary  satellite  in  situations 
of  eclipse  or  sensor  blockage  resulting  from  sun,  moon,  or  earth  interference. 

2.1.4.  Deployable  mechanism  for  sensor  or  payload  shielding 

For  spacecraft  that  experience  unanticipated  solar  illumination,  either  thermal  or  optical,  a 
SCOUT  vehicle  could  be  dispatched  to  deploy  a  lightshade  or  thermal  shield.  This  could  provide 
preferential  shading  of  key  bus  components,  including  thermally-sensitive  battery  systems,  or 
mitigate  albedo  glint  effects  or  sun  intrusion  into  payload  optics  or  attitude  sensors. 

2.2.  Near-field  Situational  Awareness 

A  SCOUT  vehicle  could  be  used  to  monitor  the  natural  or  induced  local  space  environment 
around  a  target  satellite.  In  benign  conditions,  a  SCOUT  payload  might  include  sensors  to 
measure  electromagnetic  radiation  and  ESD,  or  capability  to  detect  contamination  generated  by 
out-gassing  or  propellant  leaks.  These  functions  could  be  extended  to  include  surveillance  or 
sentinel  functions,  in  which  a  SCOUT  could  be  tasked  with  monitoring  the  vicinity  for  signatures 
of  hostile  activities. 

2.3.  Extend  Existing  Space  and  Terrestrial-based  Capabilities 

A  SCOUT  or  constellation  of  SCOUT  spacecraft  could  be  used  to  extend  US  or  Allied 
capabilities  by  leveraging  existing  space  or  terrestrial  infrastructure. 

2.3.1.  Air  Traffic  Control 

SCOUT  satellites  could  augment  current  radar-based  aircraft  tracking  systems  by  monitoring 
regional  traffic  and  relaying  gathered  information  through  global  satellite  networks. 

2.3.2.  GEO  LaserComm  MicroSat 

Using  small,  ultra  low  power  laser  transponders  on  SCOUT  satellites  in  conjunction  with  a 
centralized,  high  power  laser  transponder  for  the  return  ground  link,  communication  with 
satellites  in  LEO,  MEO  or  GEO  could  be  enabled. 


2.3.3.  Space  Surveillance 

The  coverage  of  the  NORAD  space  tracking  network 
could  be  improved  if  it  were  aided  by  SCOUT  satellites 
able  to  track  Near  Earth  Objects  (NEO)  and  small 
orbital  debris  in  orbits  of  interest. 

2.3.4.  Tactical  GPS  Microsatellite 

A  SCOUT  or  multiple  SCOUT  vehicles  could  be 
utilized  in  a  tactical  role  to  augment  or  spoof  the  Global 
Position  System  (GPS)  network  signal.  Equipped  with 
a  small-scale  GPS-compatible  transmitter  or  repeater,  a 
SCOUT  could  serve  as  an  extra  node  to  reduce  the  error 
associated  with  network  access,  known  as  Geometric 
Dilution  of  Precision  (GDOP),  or  serve  to  boost  overall 
broadcast  signal  power,  thereby  enhancing  the 
resolution  of  Position,  Velocity,  and  Time  solutions  in 
support  of  regional,  short-duration  operations.  From  an 
operational  perspective,  access  to  the  GPS  network  for 
navigation  and  orbit  determination  purposes,  could  be 
further  extended  by  providing  re-broadcast  of  system 
signals  to  space  assets  located  at  otherwise  un-served 
orbits,  such  as  GEO.  Conversely,  for  strategic 
purposes,  a  SCOUT  could  be  dispatched  to  degrade  or 
spoof  GPS  available  to  hostile  or  foreign  targets  by 
sending  out  a  false  signals  that  US  and  allied  forces 
could  ignore  by  using  P(Y)  code  messages.  In  the 
advent  of  third-generation  GPS  satellites,  SCOUT  could 
provide  a  means  of  ensuring  access  to  high  accuracy 
navigation  and  position  data  should  spectrum  become  constrained  or  precluded  by  the  further 
development  of  the  GLONASS  or  GALILEO. 

2.3.5.  Low-cost  LEO  Delivery  from  Auxiliary  Payload  to  GTO  via  Deployable  Aerobrake 

AeroAstro  is  currently  developing  significant  elements  of  the  first  Small  Payload  ORbit  Transfer 
(SPORT)  vehicle  under  Phase  II  SBIRs.  A  SCOUT-SPORT  would  provide  a  low-cost  launch 
capability  for  small  spacecraft  by  exploiting  the  excess  payload  capability  of  large  launch 
vehicles.  This  system  will  transfer  a  microsatellite  payload  from  Geosynchronous  Transfer  Orbit 
to  Low  Earth  Orbit,  after  launch  in  the  piggyback  payload  slot  of  a  major  large  launch  vehicle. 
After  release  into  GTO,  the  SCOUT-SPORT  would  deploy  a  large  aerodynamic  decelerator  and 
begin  aerobraking  at  each  perigee  pass  to  reduce  the  orbit  energy  and  thereby  lower  the  apogee. 
After  completing  a  series  of  aerobraking  passes,  the  SCOUT-SPORT  propulsion  system  would 
be  used  to  circularize  the  orbit  for  payload  release. 

2.4.  Asset  Protection 

SCOUT  could  be  utilized  to  actively  defend  an  asset  against  on-orbit  threats  or  attacks  by  hostile 
microsatellites.  Using  an  RF  or  optical  system  in  defense,  SCOUT  could  jam  communications, 
eavesdrop  or  corrupt  TT&C  signals  of  potential  threats,  or  potentially  interfere  with  the  GN&C 


capabilities  of  identified  targets.  If  warranted,  SCOUT  provides  an  option  users  for  commanded, 
“sacrificial”  intercept  of  incoming  threats.  Alternatives,  however,  also  include  use  of  deployable 
systems,  including  thin-film  shields,  nets,  or  tethered  restraints  to  block,  shield,  deflect,  or 
otherwise  interfere  with  an  aggressor  vehicle. 

2.4.1.  Orbital  Debris  Deorbiting  System 

Hostile  attacks  on  space  assets  may  use  kinetic  or 
fragmentation  projectiles  that  could  potentially 
result  in  large  strata  of  orbital  debris,  threatening 
US  and  allied  assets  in  the  same  and  adjacent 
planes.  Replacement  satellites  can  not  be  safely 
deployed  until  the  debris  is  removed.  SCOUT- 
based  spacecraft  may  be  capable  of  mitigating 
this  threat,  including  a  nanosat  Orbit  Debris 
Deorbiter,  in  which  SCOUT  vehicles  intercept 
and  capture  small  pieces  of  debris,  potentially 
using  an  aerobrake  to  aid  collection  and  deorbit. 

These  SCOUT  vehicles  could  be  re-tasked  from 
space  surveillance  and  debris  tracking  assets,  or 
deployed  via  a  RASCAL  launch  as  needed. 

2.5.  Surveillance,  Reconnaissance,  &  Tactical  Operations 

As  the  first  line  of  space-based  counter-intelligence,  SCOUT  could  employ  an  optical  or  RF 
Probe  to  gather  intelligence  data  for  foreign  or  identified  space  assets,  including  evaluation  of 
vehicle  data  links,  payload,  capability,  and  host  ground  stations.  In  addition,  SCOUT  could  be 
used  to  disrupt  the  payload  or  sensors  of  a  foreign  asset  using  an  onboard  laser  or  RF  source  to 
saturate  sensors  or  command  receivers.  In  general,  these  activities  could  be  carried  out  in  a  way 
that  is  largely  undetectable  on  Earth  and,  as  such,  disruptive  behavior  could  be  temporary  in 
nature  and  responsive  to  the  tactical  needs  of  the  conflict  or  operation. 

2.5. 1.  Hostile  Intent  Microsatellite  (HIM) 

Operators  on  ground  could  utilize  a  SCOUT-HIM  to  engage  an  adversarial  space  asset  to 
temporarily  or  permanently  disable  it.  A  SCOUT-HIM  would  allow  quick  and  covert  removal  of 
a  threatening  capability  from  a  tactical  engagement.  A  SCOUT-HIM  could  be  stealthy  so  that 
opposing  ground  operators  could  not  detect  it  and/or  react  with  countermeasures.  In  this  regard, 
a  properly  shaped  external  sheath  of  radar  absorbent  material  (for  example,  EccoSorb®  with  a 
special  formulation  of  Martin  Black  paint)  would  render  a  SCOUT-HIM  virtually  invisible  from 
RF,  optical,  or  infrared  detection.  Possible  HIM  methods  could  include  forcing  an  orbit  change 
or  degradation  or  instilling  a  body  spin-up  or  disturbance  torque  that  could  interfere  with 
operations,  attitude,  or  image  quality.  This  could  also  include  jamming,  spoofing,  or  blocking  an 
adversarial  spacecraft's  bus  subsystems  at  close  range,  including  magnetometers,  GPS  receivers, 
RF  transponders,  imagers,  or  imaging  attitude  sensors. 


2.6.  Rapid  Access  to  Space  and  Flight  Qualification  of  New  Technologies 

The  modular  and  configurable  SCOUT  architecture,  in  conjunction  with  the  highly  responsive 
deployment  capability  of  the  RASCAL  system,  would  also  enable  rapid  access  to  space  for  flight 
qualification  and  validation  of  new  technologies  for  demonstration  or  test  purposes. 

3.0  Review  and  prioritize  mission  profiles 

Based  upon  these  mission  options,  the  following  table  was  created  that  correlates  the  principal 
goals  and  intent  associated  with  each  to  top-level  functional  subsystem  requirements. 


MISSION  OPTIONS 

SUB  SYS" 

fEM 

Propu 

Ision 

ADCS 

Power 

Communications 

Co-Planar 

Transfer 

Proximity 

Coarse 

Fine 

Long 

Term 

High 

BW 

Low 

BW 

Satellite  Inspection 
&  Logistics  Services 

X 

X 

X 

X 

X 

Near-field 

Situational 

Awareness 

X 

X 

X 

X 

Extend  Existing 
Space  &  Terrestrial- 
based  Capabilities 

X 

X 

X 

X 

Asset  Protection 

X 

X 

X 

X 

X 

Surveillance, 
Reconnaissance  & 
Tactical  Operations 

X 

X 

X 

X 

Rapid  Access  & 
Flight  Qualification 

X 

X 

X 

X 

4.0  Mission  Baseline  Down-select 

Based  upon  the  review  of  these  mission  types  and  the  direction  of  the  sponsor,  the  following 
three  missions  have  been  selected  for  further  definition  and  study. 


•  Satellite  inspection  and  logistics  services 

•  Tactical  GPS  microsatellite 

•  Enable  rapid  access  and  flight  qualification  of  new  technologies 

A  detailed  design  study  commensurate  with  the  phase  of  the  program  will  be  presented  in  the 
Final  Report  and  will  be  based  on  satisfying  the  following  mission: 

•  Satellite  inspection  and  logistics  services 


This  design  will  feature  a  payload  including  an  RF  Probe  sensor  and  a  visible  light  imager. 
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SCOUT  Launch  Vehicle  Study 


1.  Document  Scope 

As  part  of  the  work  being  performed  in  support  of  the  DARPA  Phase  I  SBIR  contract  entided 
Smart  Escort  Microsatellite,  AeroAstro  is  developing  a  modular  architecture  for  small  satellites,  as 
well  as  a  conceptual  design  for  a  small  satellite  that  could  be  built  using  this  modular  architecture. 
The  modular  architecture,  as  well  as  spacecraft  which  are  built  using  it,  are  referred  to  as  S3COUT 
(Small  Smart  SpaceCraft  for  Observation  and  Utility  Tasks). 

The  modular  architecture  of  SCOUT  is  intended  to  enable  a  mass-producible  small  satellite  which  is 
complimentary  to  the  “rapid,  responsive  and  reliable”  RASCAL  launch  vehicle  concept.  By  using 
the  SCOUT  architecture,  tactical  commanders  in  the  field  will  no  longer  need  to  rely  on  a  distant 
and  sometimes  oversubscribed  homeland-based  space  capability  for  the  launch  and  operation  of 
their  satellites.  Instead,  field  commanders  will  be  able  to  field-assemble  and  configure  a  customized 
small  satellite  from  pre-built,  pre-qualified  modules,  integrate  it  to  RASCAL,  launch  it,  and  operate  it 
in  just  a  few  hours 

This  document  reports  on  work  performed  in  support  of  section  5  of  the  SBIR  contract  Statement 
of  Work  (SOW)  as  shown  below. 

5.0  Launch  Vehicle  Compatibility  Analysis 

5.1  Identify  and  analyze  RASCAL  launch  imposed  requirements  and  constraints 

^  Survey  the  RASCAL  launch  vehicle  and  develop  a  set  of  requirements 
based  on  that  vehicle 

^  Develop  a  set  of  launch  compatibility  requirements  for  the  overall 
mission 

5.2  Assess  alternate  deployment  options  and  identify  corresponding  launch  imposed 
requirements 

^  Survey  other  available  launch  vehicles 
>  Develop  set  of  requirements  based  on  those  vehicles 

2.  Introduction 

Small  satellites  (10  kilograms  to  200  kilograms)  are  increasingly  being  utilized  in  applications  such  as 
distributed  constellations,  satellite  inspection  and  engagement,  eavesdropping,  and  reconnaissance. 
The  ability  to  get  those  satellites  into  operation  quickly  and  efficiently  is  necessary  to  maintain 
information  superiority  and  space  control. 

Secondary  launches  are  a  quick,  frequent,  low-cost,  reliable  solution  for  small  satellites.  Worldwide, 
most  small  spacecraft  are  launched  as  secondary,  piggyback  payloads,  aboard  larger,  more  efficient 
rockets.  However,  piggyback  accommodations  in  the  US  are  rare,  done  only  on  a  case  by  case  basis, 
and  far  from  low  cost. 
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This  work  will  assess  current  and  future  US  secondary  launch  capabilities,  catalog  all  requirements, 
interfaces,  and  procedures,  and  create  a  tool  for  mission  planners  to  quickly  design  small  satellite 
missions.  We  will  then  develop  a  Universal  Small  Payload  Interface  (USPI),  a  template  for  launching 
small  satellites  which  developers  and  programs  can  follow  regardless  of  which  launch  vehicle  is 
ultimately  used. 

This  tool  will  deliver  rapid  access  to  space.  The  mission  planner  can  start  a  program  with  a  template 
which  he/ she  knows  will  be  applicable  to  multiple  US  secondary  accommodations.  When  nearing 
launch,  the  planner  can  select  the  most  convenient  launch  option,  since  there  will  be  several  launch 
vehicles  usable  by  the  mission.  Access  to  space  for  small  satellites  will  become  rapid,  low-cost,  and 
strategically  effective. 


3.  Background  and  Objectives 

The  Opportunity 

One  of  the  biggest  sources  of  cost  and  schedule  burden  lies  with  the  launch  phase  of  the  mission. 
Not  only  is  this  phase  of  the  mission  costly  and  often  fraught  with  delays,  but  the  constraints 
imposed  on  mission  planners  by  the  launch  vehicle  and  the  process  associated  with  it  have 
repercussions  throughout  the  program.  Small  satellites  are  extremely  limited  in  the  number  of 
launch  options  they  have.  These  options  fall  into  three  categories: 

-  Space  Shuttle  -  with  a  high  cost  due  to  safety  constraints,  a  short  lifetime  (low  altitude)  orbit,  and 

an  inclination  not  useful  for  many  missions; 

-  Dedicated  Launches  -  with  a  very  high  cost  and  a  long  launch  backlog,  often  requiring  shared 

launches  with  custom  dual  payload  adapters; 

-  Secondary  Launches  -  usually  “custom”  in  nature,  subject  to  launch  vehicle-specific  constraints, 

and  historically  unavailable  on  US  launchers,  although  that  situation  is  improving. 

None  of  the  existing  domestic  launch  options  are  designed  for  quick,  small  satellite  missions.  Small 
satellites  may  wait  years  for  a  launch  opportunity.  And  those  opportunities  may  cost  up  to  ten  times 
more  than  the  payload  The  requirements  for  tactical  responses  to  threats  cannot  be  met  under  these 
conditions. 

Secondary  launches  offer  an  avenue  for  dramatic  improvement  to  this  situation.  Worldwide,  most 
small  spacecraft  are  launched  as  secondary,  piggyback  payloads,  aboard  larger,  more  efficient 
rockets.  However,  piggyback  accommodations  in  the  US  are  rare,  done  only  on  a  case  by  case  basis, 
and  far  from  low  cost.  By  contrast,  the  French  Ariane  V  launchers  have  developed  a  standard 
secondary  configuration  which  has  enabled  a  significant  number  of  easily  accessible,  low-cost 
launches  over  the  past  decade. 

A  combination  of  greater  availability  of  standard  secondary  launch  accommodations  on  US 
launchers  and  a  degree  of  commonality  among  these  options  will  create  a  revolutionary  change  in 
the  way  small  spacecraft  missions  are  developed  and  launched.  Missions  can  be  quickly  designed 
towards  a  common  interface  standard,.  The  need  to  contract  and  customize  a  secondary  launch  on 
a  specific  vehicle  at  the  very  beginning  of  the  program  will  be  eliminated,  decreasing  cost  and 
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mission  cycle  time.  Also,  the  launch  will  not  be  dependent  on  a  specific  launch  of  a  specific  launch 
vehicle;  when  the  spacecraft  is  ready,  the  next  launch  available  will  be  used,  bringing  launch  on- 
demand’  closer  to  reality. 


4.  RASCAL  Launch  Requirements 

Table  1  below  provides  the  payload  requirements  to  meet  the  RASCAL  launch  vehicle  limits. 


Property 

Limit 

Mass 

100  kg  or  less 

Static  envelope 

1.2m  diameter  x  3.0  m  length 

Mass  moments  of  inertia 

Limited  only  by  mass  and  static  envelope 

Center  of  Gravity  (c.g.) 

Axial  -distance  from  c.g.  to  interface  plane 

1.5  m  or  less 

Lateral  -  distance  from  c.g.  to  the  vector  that 
is  normal  to  the  interface  plane  and  that 
passes  through  the  center  of  that  interface 

0.03  m  or  less 

Fundamental  frequency  when  rigidly  mounted 
at  LV  interface 

Axial 

50  Hz  or  greater 

Lateral 

40  Hz  or  greater 

Torsional 

50  Hz  or  greater 

Table  1  RASCAL  Launch  Requirements 


Explanation: 

•  Mass — The  mass  shown  is  the  limit  for  the  total  payload,  including  any  needed  upper  stage. 

•  Static  envelope — This  is  the  physical  space  in  which  the  payload  must  stay  in  the  static, 

unloaded  condition.  The  LV  shall  provide  a  dynamic  envelope  large  enough  to  ensure  a 
payload  with  the  static  envelope  and  fundamental  frequencies  given  above  will  not  make 
physical  contact  during  launch  with  any  part  of  the  launch  vehicle.  The  dynamic 
envelope  shouldaccommodate  rigid-body  deflections  of  the  payload  resulting  from 
deformation  of  the  mounting  structure  combined  with  the  elastic  deformation  of  the 
payload  under  maximum  expected  launch  loads. 

•  Mass  moments  of  inertia — self  explanatory. 

•  Center  of  gravity — These  limits  are  arbitrary  and  are  suggested  as  a  starting  point.  If  these 
values  drive  system  complexity  or  cost,  it  is  acceptable  to  derive  reasonable  alternatives  that 
can  be  specified  to  payload  organizations. 

•  Fundamental  frequency — These  values  are  also  arbitrary  and  intended  as  reasonable  lower 
limits  for  payloads  up  to  100  kg.  They  are  suggested  as  a  starting  point  for  designing  an  LV 
control  system  and  meeting  the  environment  objectives.  Reasonable  alternatives  acceptable. 
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5.  US  Piggyback  Capability  Assessment 

This  section  provides  historical  data  on  piggyback  launches  and  current  and  future  piggyback 
accommodations.  The  assessment  used  the  Ariane  launcher  and  its  ASAP  5  adapter  as  a  benchmark 
to  highlight  the  opportunities  available  for  small  satellites  with  standard  piggyback  payload  adapters 
and  proactive  launch  policies. 


5.1  Universal  Small  Payload  Interface 

The  Universal  Small  Payload  Interface  is  a  design  template  and  an  interface  standard.  The  design 
template  provides  small  and  micro-satellite  designers  the  basic  design  requirements  to  launch 
piggyback  on  a  USPI-compatible  vehicle1.  The  interface  standard  provides  the  designers  a  set  of 
standard  mass-volume  classes2,  a  standard  interface3,  and  an  accommodation  platform.  USPTs 
logistical  concept  is  described  in  Figure  6  below. 


Large  Launch  Vehicle  Launches 
with  Available  Launch  Mass 
Margin 


USPI  Standard: 

•  Launch  database 

•  Requirements 

•  Integration  Flow 

•  Standard  Interface 

•  Standard  Accommodations 

Conceptually: 

A  Universal  Leading 
Device  (ULD) 


Figure  2:  Logistical  concept  for  USPI . 

Essentially,  we  need  a  process  to  get  missions  and  experiments  on  large  LS/s  with  capacity  using  a  standard  that  provides  the  maximum  possible 
number  of  missions. 


A  quick,  cost-effective  method  to  get  high-risk  technologies  into  space  to  test  the  concepts  before 
they  have  to  commit  large  funds  to  a  full  mission  is  needed. 


1  Henceforth,  this  document  will  use  the  shorthand  USPI  standard  to  mean  a  design  that  satisfies  the  design, 
interface,  and  accommodations  standards  to  launch  piggyback  on  a  launcher  covered  by  USPI. 

2  The  mass-volume  class  defines  the  actual  physical  volume  the  piggyback  payload  must  fit  in. 

The  standard  interface  is  the  separation  system  and  the  bolt  pattern  required  of  it. 
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•  Have  a  standard  set  of  requirements  to  design  to  -  the  user  knows  that  if  their  design 
fits  the  USPI  requirements,  they  will  fit  on  a  large  number  of  LVs. 

•  Have  a  standard  accommodation  template  -  allows  the  piggyback  payload  to  fit  in 
the  widest  possible  variety  of  LVs. 

•  Allow  LV  contractors  easy  integration  -  as  long  as  the  piggyback  payload  complies 
with  USPI,  the  contractors  know  they  can  easily  integrate  the  payload  onto  their  LV. 

•  Allow  quick  mission  turnaround  -  it  does  not  matter  how  long  the  piggyback 
payload  takes  to  design,  build  and  test.  Once  it  is  ready,  it  can  go  on  the  next  most 
convenient  mission  because  the  USPI  standard  allows  it  to  fit  on  any  of  the  USPI 
LVs. 

•  Allows  the  LV  to  disengage  from  the  piggyback  payload  schedule  -  the  LV  can  take 
the  piggyback  payload  or  a  standard  dummy  mass4  instead.  If  the  piggyback  payload 
is  late,  the  LV  can  launch  with  the  dummy  mass  and  not  worry  about  the  mass 
balance  of  the  LV. 

The  launchers  selected  for  consideration  in  the  USPI  standard  are  shown  in  Table  3  below. 


Table  3:  Launch  Vehicles  Considered  in  USPI 


Ariane  4,  5 

K  1 

H II A 

Adas  II,  III,  V 

Kosmos 

Sealaunch 

Delta  II,  III,  IV 

Minotaur 

STS 

Eurockot 

Pegasus 

Taurus 

5.2  USPI  Requirements  Document 

The  requirements  document  is  a  template  for  a  USPI-compatible  payload  design.  The  USPI 
requirements  document  ensures  that,  if  followed: 

•  The  payload  shall  fit  in  the  piggyback  accommodations  provided  on  any  of  the 
USPI-compatible  LVs  shown  in  Table  5  above. 

•  The  payload  shall  comply  with  the  worst-case  environmental  requirements  for  the 
USPI  LVs.  Therefore,  the  payload  will  have  the  maximum  possible  LV  flexibility. 

The  requirements  document  provides  the  design  discipline  to  make  the  tradeoffs  required  for 
mission  success. 

The  most  stringent  launcher  environmental  requirements  are  needed  to  qualify  a  payload  on  any 
existing  LV.  The  USPI  requirements  synthesize  all  the  environments  a  payload  is  exposed  to  on 
any  of  the  twenty  US  or  European  LVs  considered.  Table  5  is  a  list  of  all  the  launchers  considered. 
Most  LVs  divide  their  launch  and  flight  environments  into  similar  categories.  Table  4  is  a  list  of  the 
environmental  categories  used  to  describe  the  worst  case-loads  applied  to  a  payload  during  launch. 


4  Please  see  the  USPI  requirements  document  for  the  requirement  for  the  dummy  mass.  Essentially,  the  dummy 
mass  is  a  mass  and  volume  substitute  for  the  actual  payload. 
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Table  4:  Environmental  Categories  Used  to  Compare  LVs. 


Acoustic 

Electro  Magnetic  Interference  (EMI) 

Shock 

Fairing  Pressure 

Low  Frequency  Vibration 

Fairing  Wall  Temperature 

Quasi-Static  Load 

Testing  Factors 

5.3  USPI  Mass  &  Volume  Classes 

The  ESPA  is  not  considered  in  the  USPI  mass  volume  classes  for  a  series  of  technical  reasons.  The 
general  ESPA  configuration  is  shown  in  Figure  6  below.  The  ESPA  adapter  sits  atop  the  standard 
EELV  PAF.  The  piggyback  payloads  are  arranged  radially  from  the  ESPA  adapter. 


Figure  6:  ESPA  Piggyback  Payload  Adapter. 

The  six  blue  boxes  are  the  piggyback  payloads,  attached  to  the  cylindrical  adapter.  The  payload  is  the  large  red  structure. 

The  standard  ESPA  payload  is  610  mm  x  610  mm  x  965  mm  with  170  kg  mass.  The  bolt  pattern  is 
non-standard,  and  there  seems  to  be  no  standard  separation  system.  As  a  payload  accommodation, 
the  ESPA  provides  a  lot  of  mass  and  volume  for  die  piggyback  payload.  But  by  maximizing  the 
payload  mass  and  volume  available,  the  ESPA  payload  does  not  adhere  to  the  ASAP  standard.5 
Configured  as  such,  they  would  also  be  less  likely  to  fit  in  other  LVs.  Therefore,  the  ESPA 
configuration  is  not  considered  in  the  USPI  mass  volume  classes. 

Three  mass  and  volume  classes  maintain  some  standardization  without  sacrificing  too  much 
flexibility.  It  is  therefore  possible  to  have  mission  flexibility  at  the  expense  of  optimal  use  of 
available  mass  and  volume  on  a  given  launch.  The  three  classes  are  shown  in  Table  5  below. 


Table  5:  USPI  Mass  and  Volume  Classes. 


Class 

Volume 

Mass 

Comments 

Class  I 

400  mm  X  400  mm  X  250  mm 

25  kg 

Smallest  class,  still  can  fit  ASAP 

5  38.5  sep.  system 

Class  II 

440  mm  X  440  mm  X  500  mm 

75  kg 

Will  fit  on  ASAP  5  sep  system 

Also  fit  on  small  launchers 

5  The  only  other  large  launch  vehicle  piggyback  payload  standard. 
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Class  III 

600  mm  X  600  mm  X  710  mm 

120  kg 

ASAP  5  Micro  piggyback 

payload  standard. 

5.3.1  Class  I 


Mass-volume  Class  I  is  the  smallest  USPI  standard.  The  general  aspect  is  flat  for  this  class 
because  the  400  mm  X  400  mm  footprint  is  required  as  a  minimum  to  accommodate  the  348 
mm  ASAP  5  Micro  baseline  separation  system.  The  bolt  pattern  is  common  with  the 
other  mass-volume  classes.  As  configured,  the  Class  I  USPI  payloads  will  fit  as 
piggyback  payloads  on  the  following  LVs  without  modification: 

Pegasus  XL  DPAF6 

Taurus  DPAF 


•  Minotaur  -  using  the  OSSS7  Multiple  Payload  Adapter 

•  Delta  II  Secondary  Payload  accommodations8 

•  ASAP  5  Standard  -  Ariane  5,  Soyuz  ST-Fregat,  Eurockot,  PSLV,  K  1 

•  STS  Hitchhiker 


•  Kosmos  -  using  a  DPAF-like  structure  in  place  of  the  “load  bearing  satellite”9 

•  Proton  -  in  the  non-standard  accommodations  for  piggyback  launches  on  Proton 


In  addition,  the  standard  accommodation  concept  presented  in  section  3.5  can  accommodate  Class  I 
payloads  at  a  minimum.  The  Sealaunch  vehicle  has  not  shown  interest  in  piggyback  launches. 
Discounting  that  LV,  Class  I  payloads  can  fit  on  any  of  the  LVs  considered  either  without 
modification  on  existing  piggyback  accommodations  or  on  the  standard  piggyback  payload. 


5.3.2  Class  II 


This  class  has  a  440  mm  X  440  mm  X  509  mm  volume  with  an  allowable  maximum 
mass  of  75  kg  without  the  separation  system.  This  class  also  accommodates  the  348 
mm  ASAP  5  Micro  baseline  separation  system  and  has  the  bolt  pattern  common 
with  Class  I  and  Class  III.  As  configured,  the  Class  II  USPI  payloads  will  fit  as 
piggyback  payloads  on  the  following  LVs  without  modification: 


50  inch  and  63  inch  Taurus  DPAFs 


•  Minotaur  -  atop  the  OSSS  Multiple  Payload  Adapter 

•  ASAP  5  Standard  -  Ariane  5,  Soyuz  ST-Fregat,  Eurockot,  PSLV,  K  1 


6  Dual  Payload  Attachment  Fitting. 

7  One  Stop  Satellite  Solutions,  Ogden,  UT  84408-1805. 

8  However,  the  separation  system  is  not  standard  for  Delta  II. 

9  Cosmos  3M  Launch  Vehicle  Users  Guide,  United  Start  Corporation,  190  Lime  Quarry  Road,  Suite  106-J,  Madison, 
AL  35758 
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•  Kosmos  -  using  a  DPAF-like  structure  in  place  of  the  "load  bearing  satellite”10 

•  Proton  —  in  the  non-standard  accommodations  for  piggyback  launches 

The  standard  accommodation  concept  presented  in  section  3.5  will  also  accommodate  Class  II 
payloads.  Discounting  the  Sealaunch  vehicle,  Class  II  payloads  can  fit  on  the  LVs  above  without 
modification  on  existing  piggyback  accommodations  or  on  the  standard  piggyback  payload 
accommodations  described  in  Section  3.5.  However,  inserts  will  be  required  on  the  standard  PAFs 
to  raise  the  primary  payloads  to  accommodate  the  taller  Class  II  payloads  on  the  standard 
accommodation.  The  inserts  will  be  less  than  550  mm,  but  the  loss  -  or  perception  thereof  -  of 
height  available  to  the  primary 


5.3.3  Class  III 


Mass  volume  Class  III  is  the  same  size  and  mass  as  the  ASAP  5  Micro  class  payload. 
Class  III  has  600  mm  X  600  mm  X  710  mm  volume  and  120  kg  without  the 
separation  system.  The  bolt  pattern  and  interface  remain  the  same  as  the  other  two 
classes.  As  configured,  Class  III  USPI  payloads  will  fit  as  piggyback  payloads  on  the 
following  LVs  without  modification: 


•  63  inch  Taurus  DPAFs 


•  Minotaur  —  using  the  OSC  63  inch  DPAF 

•  ASAP  5  Standard  -  Ariane  5,  Soyuz  ST-Fregat,  Eurockot,  PSLV,  K  1 

•  Kosmos  -  using  a  DPAF-like  structure  in  place  of  the  "load  bearing  satellite”11 

•  Proton  -  in  the  non-standard  accommodations  for  piggyback  launches 
The  following  tables  shows  the  worst-case  requirements  for  each  launcher  considered: 


10  Cosmos  3M  Launch  Vehicle  Users  Guide,  United  Start  Corporation,  190  Lime  Quarry  Road,  Suite  106- J, 
Madison,  AL  35758 

11  Cosmos  3M  Launch  Vehicle  Users  Guide,  United  Start  Corporation,  190  Lime  Quarry  Road,  Suite  106-J, 
Madison,  AL  35758. 
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6.  Combined  Launch  Vehicle  Requirements 

Class  I  and  Class  II  USPI  are  compatible  with  RASCAL  LV  requirements.  The  payload  should  be 
designed  to  these  worst-case  limits: 


Prope 


Mass 


Static  Envelope 


Longitudinal  Fundamental  Frequenc 


Lateral  Fundamental  Frequenc 


Torsional  Fundamental  Frequenc 


Maximum  Longitudinal  Load 


Maximum  Lateral  Load 


Limit 


75k 


440  mm  X  440  mm  X  500  mm 


35Hz 


40Hz _ 

50Hz 
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1.  Document  Scope 

As  part  of  the  work  being  performed  in  support  of  the  DARPA  Phase  I  SBIR  contract  entitled 
Smart  Escort  Microsatellite,  AeroAstro  is  developing  a  modular  architecture  for  small  satellites, 
as  well  as  a  conceptual  design  for  a  small  satellite  that  could  be  built  using  this  modular 
architecture.  The  modular  architecture,  as  well  as  spacecraft  which  are  built  using  it,  are  referred 
to  as  S3COUT  (Small  Smart  Spacecraft  for  Observation  and  Utility  Tasks). 

The  SCOUT  modular  architecture  is  intended  to  exhibit  the  following  attributes: 

1.  Small  and  Lightweight  to  maximize  utility  within  the  limited  performance  envelope  of 
modest  launch  vehicle  capabilities; 

2.  Universally  Compatible  to  enable  using  as  many  different  launch  vehicles  as  possible; 

3.  Low  Cost  to  assure  that  assets  can  be  readily  expended  as  necessary  to  serve  US  national 
security  needs  effectively; 

4.  Rapid  Response  to  allow  US  forces  to  swiftly  react  to  any  tactical  or  strategic  situation 
with  readily  available  assets; 

5.  Flexible  to  permit  a  modest  complement  of  off-the-shelf  elements  to  address  a  wide- 
ranging  set  of  scenarios; 

6.  Field  Configurable  to  enhance  the  utility  and  productivity  of  the  system  by  allowing  the 
widest  possible  application; 

7.  Modular  to  achieve  the  conflicting  goals  described  above; 

8.  Scaleable  to  tailor  the  capability  to  a  range  of  applications; 

9.  Extensible  to  allow  the  system  to  adapt  to  future  needs. 

These  characteristics  of  SCOUT  are  intended  to  enable  a  mass-producible  small  satellite 
architecture  which  is  complimentary  to  the  “rapid,  responsive  and  reliable”  RASCAL  launch 
vehicle  concept.  By  using  the  SCOUT  architecture,  tactical  commanders  in  the  field  will  no 
longer  need  to  rely  on  a  distant  and  sometimes  oversubscribed  homeland-based  space  capability 
for  the  launch  and  operations  of  their  satellites.  Instead,  field  commanders  will  be  able  to  field- 
assemble  and  configure  a  customized  small  satellite  from  pre-built,  pre-qualified  modules.  By 
utilizing  RASCAL  for  launch,  together  with  innovative  autonomy  and  ground  station  concepts 
for  operations,  field  commanders  will  also  be  able  to  launch  and  control  their  satellites  within  a 
few  hours. 

This  document  reports  on  work  performed  in  support  of  section  3  of  the  SBIR  contract  Statement 
of  Work  (SOW)  as  shown  below. 

3.0  Technology  Assessment 

3.1  Identify  key  technologies  necessary  to  implement  the  SCOUT  architecture 

3.2  Identify  existing  and  projected  technologies  to  satisfy  these  needs 

3.3  Assess  availability  and  state  of  development  of  identified  technologies 

3.4  Identify  ongoing  technology  development  that  can  be  leveraged 

3.5  Assess  alternate  or  substitute  technologies  where  existing  technologies  are  not 
expected  to  be  sufficiently  mature 
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3.6  Prepare  a  technology  utilization  and  development  plan 
2.  Architectural  Concepts 

The  following  numbered  technologies  and  features  are  considered  important  to  implement  the 
SCOUT  architecture: 

2.1  Mechanical 

1.  Stackable  plug-and-play  component-level  module  ‘slices’  for  small  spacecraft,  as  shown 
in  Figure  1; 

2.  A  robust  modular  assembly  concept  that  enables  qualified  technicians  to  field-assemble 
small  satellites  as  needed  in  a  field-deployable  facility; 

3.  A  single  uniform  structural  outer  shell  module  housing  that  can  also  serve  as  the  primary 
structure,  as  shown  in  Figure  2; 

4.  A  single  uniform  standard  for  mechanical  interfaces  and  electrical  connectors  between 
modules,  as  shown  in  Figure  2; 


Figure  1:  Stack  of  component-level  modules  Figure  2:  Single  module 

Figure  2  shows  an  avionics  module  consisting  of  a  single  printed  circuit  board  (PCB).  It  should 
be  noted  that  the  modularization  concept  is  not  limited  to  PCBs.  As  conceived,  a  single  module 
may  also  contain  sensor,  actuator,  propulsion,  deployable  and  other  elements,  as  shown  in  Figure 
4. 

5.  A  single  uniform  keyed  footprint  and  mating  joint  for  the  mechanical  interfaces  between 
modules,  as  shown  in  Figure  3; 

6.  A  rectilinear  outline  for  each  module  in  order  to  promote  efficient  packaging  of  typical 
electronic  component  parts,  as  shown  in  Figure  3,  non-rectilinear  PCBs  tend  to  have  large 
amount  of  unused  space; 

7.  The  ability  to  grow  the  volume  of  a  module  slice  by  designing  increased  heights  in  unit 
step  sizes  of  approximately  2  cm,  as  shown  in  Figure  4; 

8.  A  connecting  rod  feature  at  each  comer  of  each  module,  as  shown  in  Figure  3; 
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9.  The  ability  of  four  threaded  rods  to  hold  the  central  tower  together,  as  shown  in  Figure  1 ; 

10.  The  ability  of  the  central  tower  structure  composed  of  the  structural  outer  shells  of  the 
modules  to  carry  the  launch  loads; 

1 1 .  The  ability  for  larger  modules  or  modules  with  attachments  to  extend  outside  the  central 
tower,  as  shown  in  Figure  5; 

12.  A  thermally  conductive  path  along  the  structural  outer  shell  to  isothermalize  the  bus; 

13.  The  ability  to  add  external  structural  stiffeners  to  meet  more  demanding  launch  vehicle 
load  requirements  without  compromising  the  mass  budget  for  launch  vehicles  with  less 
stringent  load  requirements; 

2.2  Electrical 

14.  A  uniform  pass-through  connector  in  a  specified  location;  preference  is  to  use  a  single 
electrical  interface  connector,  as  shown  in  Figure  3; 

15.  The  ability  for  the  stacked  modules  to  form  an  RF-tight  box  around  the  internal 
components  of  each  module,  as  notionally  shown  in  Figure  1  and  Figure  2  (where  the 
metal  plate  at  the  bottom  of  each  module  is  shown  protruding  downwards); 

16.  An  electromagnetic  interference  (EMI)  labyrinth  seal  that  is  incorporated  with  the 
structural  outer  shell  of  each  module,  as  shown  in  Figure  3; 

17.  A  method  for  providing  all  data  needed  to  verify  proper  operation  of  any  module  in  the 
field  through  the  pass-through  connector; 


Payload 


CPU 


Transponder 


GPS 


Attitude 

Sensor 


Attitude 

Actuator 


Battery  with 
Charge  Electronics 


Solar  Array  with 
Shunt  Electronics 


Figure  3:  Single  module  features 


Figure  4:  Stack  of  different  modules 


18.  A  data  and  power  bus  to  join  all  the  modules  in  the  stack  together  electrically  (not  all 
modules  will  necessarily  require  interfaces  to  all  elements  of  the  electrical  bus,  as  shown 
in  Figure  6); 

>  Power  -  Most  likely  28  ±  6  VDC  to  keep  currents  low  and  increase  commonality  with 
conventional  spacecraft  electronics  (TBR); 

>  Low  Speed  Data  -  Carries  command,  power  enable,  current  and  temperature 
telemetry,  and  low-speed  data; 
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>  High  Speed  Data  -  This  is  an  optional  data  bus  interface  which  many  modules  will 
not  use,  reserved  for  high  speed  data  such  as  imagery,  attitude  and  orbit  data,  etc.; 

>  It  is  possible  that  some  or  all  of  these  buses  will  be  redundant  for  reliability; 

19.  A  method  for  loading  readily  available  software  drivers  while  on  the  ground  or  in  space; 

20.  A  method  for  automatically  configuring  the  attitude  determination  and  control  software 
to  work  for  any  combination  of  stacked  modules; 

21.  A  software  Built-In-Test  (BIT)  capability  for  each  module  independently  as  well  as  the 
satellite  as  a  whole,  for  use  on  the  ground  and  in  space; 

22.  A  method  for  making  the  high-level  software  platform-independent,  to  facilitate  future 
upgrades  of  computing  hardware; 


Figure  5:  High  level  diagram  of  SCOUT  modular  architecture 


2.3  Modules 
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23.  A  computer  module  (nominally  this  module  would  include  a  Central  Processing  Unit 
(CPU)  chip,  but  for  some  simple  missions  a  hardwired  Field  Programmable  Gate  Array 
(FPGA)  logic  board  may  be  sufficient); 

24.  An  Electrically  Erasable  Programmable  Read  Only  Memory  (EEPROM)  capability  on 
the  computer  module  to  allow  upload  of  code  during  field  integration  and  possibly  during 
flight; 

25.  A  solid-state  data  storage  module  for  non-volatile  storage  of  large  data  volumes; 

26.  An  RF  communications  modules  (nominally  this  would  be  an  X-  or  S-Band  transponder 
for  communicating  directly  with  ground  stations,  but  for  increased  link  availability, 
communications  links  to  space-based  networks  such  as  INMARSAT,  Globalstar,  Iridium, 
or  TDRS  could  be  used); 

27.  A  conformal  or  self-contained  antenna  for  the  communications  module  (this  could  be  a 
conformal  antenna  such  as  a  belly-band,  a  patch  or  a  microstrip,  or  deployable  such  as  a 
unipole  or  dipole); 

28.  The  ability  to  add  encryption  and  decryption  to  the  communications  module; 

29.  A  GPS  receiver  module; 

30.  An  attitude  determination  module  (possibly  containing  four  miniature  star  trackers  with 
different  boresights,  three  orthogonal  MEMS  gyrochips,  a  three-axis  magnetometer,  and 
orthogonal  sun  sensors,  as  shown  in  Figure  7); 

31.  A  three-axis  magnetic  actuator  module  (featuring  magnetic  torque  rods  on  the  sides  and 
magnetic  torque  coils  printed  on  one  or  more  stacked  PCBs,  as  shown  in  Figure  8); 

32.  A  three-axis  micro-wheel  module  for  performing  attitude  actuation,  momentum-dumping 
and  power  storage,  as  shown  in  Figure  9; 


Figure  7:  Attitude  Determination  Module  Figure  8:  Magnetic  Actuation  Module 
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Figure  9:  Micro-Wheel  Module  Figure  10:  Payload  Attach  Fitting  Module 


33.  A  divert  propulsion  module  with  one  divert  thruster,  four  attitude  control  thrusters  in  a 
double-V  configuration,  and  tankage,  as  shown  in  Figure  5; 

34.  A  maneuvering  propulsion  module  with  at  least  six  maneuvering  thrusters  and  tankage, 
with  one  of  these  modules  at  each  end  of  the  stack,  but  flipped  upside-down  relative  to 
each  other  (or  otherwise  correctly  configured),  then  uncoupled  6-DOF  translation  and 
rotation  is  possible; 

35.  Toroidal,  conformal,  or  otherwise  not  rounded  propellant  tanks  for  increased  propulsion 
mass  efficiency; 

Increased  performance  from  propulsion  modules  could  be  achieved  by  allowing  tanks  or  thruster 
arms  to  extend  above  or  below  the  height  of  their  module  slice.  However,  to  facilitate 
modularity  no  part  of  the  propulsion  modules  should  extend  above  or  below  the  module  height. 
This  is  a  case  where  reduced  performance  should  be  accepted  to  facilitate  modularity. 

36.  A  chemical  battery  module,  including  both  primary  batteries  for  short  duration  missions 
and  secondary  (rechargeable)  batteries  with  a  charger  for  longer  duration  missions 
(Lithium-Ion  cells  are  a  likely  candidate); 

37.  A  deployable  solar  array  module  with  associated  power  electronics; 

The  solar  array  panels  should  be  deployable  since  body-mounted  solar  array  panels  would  be 
difficult  to  implement  using  the  stacked  module  concept.  High  efficiency  solar  cell  technologies 
should  be  incorporated  for  increased  power.  A  tracking  array  module  may  be  required  to  get  the 
maximum  power  utilization  from  the  small  deployed  arrays.  Peak  Power  Tracker  topologies 
may  also  be  incorporated  to  provide  the  maximum  power  efficiencies  from  the  expected  small 
solar  cell  areas. 

38.  A  different  PAF  (Payload  Attach  Fitting)  Interface  Module  (PIM)  for  each  type  of  launch 
vehicle,  as  shown  in  Figure  10  (Note  that  PIMs  will  probably  be  truss-work  assemblies, 
unlike  the  example  shown  in  Figure  10.  Numerous  PIMs  are  required  to  ensure  that 
SCOUT  is  compatible  with  as  many  different  launch  vehicles  as  possible.  The  PIM  will 
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interface  with  the  standard  separation  switches  provided  at  the  LV  end  and  will  provide  a 
fail-safe  separation  indication  to  SCOUT  to  initiate  deployments); 

39.  A  separation  module  to  allow  jettisoning  the  PIM  to  maximize  use  of  available 
propellant; 

40.  A  Master  Universal  Ground  Support  Equipment  (MUGSE)  to  enable  field-assembly, 
configuration  and  limited  functional  testing,  as  shown  in  Figure  1 1  and  Figure  12; 

The  MUGSE  will  consist  of  a  laptop  computer  loaded  with  the  latest  software,  a  base-plate  upon 
which  the  stack  of  SCOUT  module  slices  is  assembled,  and  a  cable  between  the  laptop  and 
baseplate.  MUGSE  will  have  the  ability  to  test  out  individual  modules  or  a  fully  integrated 
SCOUT  satellite.  The  MUGSE  base  plate  will  include  a  standard  mechanical  footprint  with  a 
standard  electrical  interface  connector,  as  shown  in  Figure  12.  When  a  module  is  mounted  on 
MUGSE,  it  can  be  powered,  commanded,  functionally  tested,  and  fully  characterized. 
Additional  modules  can  be  added  one  at  a  time  until  an  entire  satellite  is  built  up  and  tested  in  the 
field.  MUGSE  will  also  be  used  to  upload  the  latest  generation  of  SCOUT  software;  each 
version  will  include  data  necessary  to  command  every  possible  module  variant  in  the  inventory. 


Figure  11:  MUGSE  Next  to  SCOUT  Figure  12:  MUGSE  Base  Plate 


41.  An  efficient  production  system  for  low- volume  mass-production  and  qualification  of 
modules; 

3.  Technology  Candidates 

Many  of  the  technologies  identified  in  this  assessment,  particularly  mechanical  and  software 
technologies,  do  not  exist  and  are  not  projected  to  exist  unless  AeroAstro  is  funded  to  continue 
development  of  SCOUT.  Nonetheless,  some  existing  and  projected  technologies  may  be 
candidates  for  incorporation  into  SCOUT.  Some  of  these  identified  technologies  are  described 
below.  The  availability  and  state  of  development  of  these  identified  technologies  is  also 
assessed. 
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3. 1  Electrical  Bus  Technologies 

The  SCOUT  electrical  bus  architecture  consists  of  two  different  data  buses,  one  that  is  suitable 
for  low  data  rate  applications  such  as  commanding  and  telemetry  and  one  that  is  suitable  for  high 
data  rate  applications  such  as  imaging.  For  purposes  of  this  discussion,  any  bus  with  a  data  rate 
below  1  Mbps  is  considered  to  be  low  data  rate,  and  any  bus  with  a  data  rate  above  1  Mbps  is 
considered  to  be  high  data  rate. 

The  following  characteristics  of  different  electrical  buses  were  analyzed  and  traded  to  determine 
which  were  best  suited  for  SCOUT: 

>  Backplane/Cable:  Do  all  participants  on  the  bus  need  to  be  in  the  same  box  (as  in  a 
VME  architecture),  or  can  they  be  distributed  around  the  spacecraft  (like  a  USB  bus)? 

>  Central/Distributed:  Is  there  one  central  governing  device  which  controls  who  can 
transmit  on  the  bus  at  any  one  given  time,  or  all  the  devices  on  the  bus  participate  in 
arbitration  to  decide  who  can  transmit  or  have  priority? 

>  Number  of  Wires:  The  number  wires  that  are  required  for  the  bus 

>  Max  Length:  The  maximum  physical  length  of  the  bus 

>  Data  Rate:  The  maximum  data  rate  of  the  bus 

>  Payload  Fraction:  The  maximum  number  of  information  bits  that  are  transmitted, 
versus  header  or  other  bits  (i.e.,  transmission  efficiency  or  overhead) 

3.1.1  Low  Data  Rate  Electrical  Bus  Technologies 

1.  I2C:  An  industry  standard  serial  bus  that  can  link  multiple  devices  off  the  same  2  wire 
connections.  It  is  a  low  data  rate  bus,  -400  kbps,  and  is  typically  used  on  a  single  card  or 
over  a  backplane 

>  Pros  -  Widely  used  with  a  lot  of  devices  available  to  interface 

>  Cons  -  Low  data  rate,  short  distance,  poor  noise  immunity  (single  ended  signals) 

2.  Bluetooth:  A  communications  standard  for  short-distance  wireless  connections.  It 
replaces  the  many  proprietary  cables  that  connect  one  device  to  another  with  one 
universal  short-range  radio  link.  The  data  is  transmitted  at  a  data  rate  of  no  greater  than 
723.2  kbps  over  a  frequency  of  2.4  GHz  (unlicensed  band).  Three  power  classes  are 
available  for  Bluetooth: 

❖  100  mW,  20  dBm,  100  m 

❖  2.5  mW,  4  dBm,  10  m 

❖  1  mW,  0  dBm,  10  cm 

>  Pros  -  Widely  used  industry  standard,  small  form  factor,  no  cabling 

>  Cons  -  EMI/EMC  concerns 

3.  CAN:  A  simple  two- wire  differential  serial  bus  system,  the  CAN.bus  operates  in  noisy 
electrical  environments  with  a  high  level  of  data  integrity,  and  its  open  architecture  and 
user-definable  transmission  medium  make  it  extremely  flexible.  Capable  of  high-speed  (1 
Mbps)  data  transmission  over  short  distances  (40  m)  and  low-speed  (5  kbps) 
transmissions  at  lengths  of  up  to  10,000  m,  the  multi -master  CAN.bus  is  highly  fault 
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tolerant,  with  powerful  error  detection  and  handling  designed  in.  (Taken  from  Philips 
web  page.) 

>  Pros  -  Excellent  noise  immunity,  well  defined  electrical,  protocol  and  application 
layers 

>  Cons  -  Power  hungry 

4.  1553:  An  avionics  command  and  control  bus  that  can  interface  up  to  32  devices  on  a 
differential  serial  interface.  The  specification  can  handle  data  rates  up  to  1  Mbps  (Mil- 
Std-1773,  optical  version  can  handle  20  Mbps) 

^  Pros  —  Widely  used  on  military  aircraft  and  spacecraft 

>  Cons  -  Software  intense,  low  data  rate  not  suitable  for  massive  data  transfer, 
significant  amount  of  overhead  required  in  protocol,  lots  of  supporting  interface 
electronics  such  as  termination  resistors  and  transformers 


Table  1:  Summary  of  Low  Data  Rate  Electrical  Bus  Technologies 


Backplane/ 

Cable 

Central/ 

Distributed 

Num 

Wires 

Data 

Rate 

Payload 

Fraction 

|  I-C 

Cable 

Distributed 

2 

-4  m 

400  Kbps 

-85%  1 

Bluetooth 

N/A 

Distributed 

wireless 

100  m 

BSQSsSH 

72.3% 

CAN 

Cable 

Distributed 

2 

40  m 

H  ESS 

59% 

1553 

Cable 

Central 

2 

~50  m 

1  Mbps 

75% 

After  considering  the  different  low  data  rate  buses  for  SCOUT,  I2C  was  selected  for  the 
following  reasons 

>  Low  Overhead 

>  Commercially  Available 

>  Low  Software  Loading 

>  Low  power 

>  Multi-drop 

3.1.2  High  Data  Rate  Electrical  Bus  Technologies 

5.  IEEE  803.2  Fast  Ethernet:  An  industry  standard  telecommunications  interface  widely 
used  to  integrate  telecommunications  equipment  and  computers  into  local  area  networks. 
Embedded  system  designers  are  turning  to  Ethernet  to  solve  the  challenge  of  providing 
communication  links  between  printed  circuit  boards  (PCBs)  in  chassis-based  networking 
equipment.  Ethernet  is  an  ideal  technology  for  interconnecting  multiple  line  cards  and 
modules  within  telecommunications  equipment  backplanes  and  is  widely  displacing  high¬ 
speed  serial  and  proprietary  communication  protocols.  Ethernet  can  handle  data  rates  up 
to  100  Mbps  and  distances  of  35  m  over  twisted  pair  cable  or  1  m  over  a  backplane. 
Implementing  Ethernet  in  backplane  solutions  provides  many  benefits.  As  a  standards- 
based  technology,  Ethernet  is  available  from  several  silicon  manufacturers,  eliminating 
concerns  of  single-source  supply.  In  addition,  Ethernet  uses  innovative  filtering  and 
scrambling  techniques  to  provide  a  high  level  of  data  integrity  and  noise  suppression,  and 
has  the  built-in  capability  to  check  for  data  corruption. 


AeroAstro  Inc. 


12 


Making  Space  for  Everyone 


AeroAstro 


>  Pros  -  Widely  used  standard,  unlimited  number  of  products  to  interface,  eases  ground 
support  interface  of  spacecraft 

>  Cons  -  Not  generally  used  in  a  space  environment,  would  have  to  use  industrial 
components 

6.  VME:  A  modular  data  bus  with  data  bus  sizes  of  16,  32  or  64  bits  and  follows  the 
Eurocard  form  factor.  The  16  and  32  bit  versions  have  dedicated  address  and  data 
signals.  The  64  bit  version  multiplexes  the  address  and  data  signals  on  the  same  nets.  A 
VME  bus  system  consists  of  a  controller,  a  master  (controller  and  master  can  be  the  same 
device)  and  a  slave  and  can  be  capable  of  data  rates  of  up  to  160  MBps. 

>  Pros  -  Modular,  industry  standard 

>  Cons  -  Bulky  form  factor,  terminations  may  be  required  on  backplane 

7.  SCSI:  A  16  bit  wide  bus  capable  of  handling  data  rates  of  up  to  80  MBps.  SCSI  devices 
are  usually  connected  to  a  controller  through  a  cable  and  not  a  backplane. 

>  Pros  -  Widely  used  and  recognized  interface  in  the  PC  industry 

>  Cons  -  More  than  one  industry  standard,  not  all  SCSI  devices  are  compatible,  only 
one  controller  permitted  on  the  bus 

8.  USB  2.0:  Also  known  as  Hi-speed  USB.  The  Universal  Serial  Bus  (USB)  is  a  serial 
interface  which  can  link  up  to  127  devices  on  one  serial  bus.  The  maximum  data  rate 
over  the  bus  is  480  MBps. 

>  Pros  -  High  data  rate,  compatibility  with  other  USB  devices 

>  Cons  -  Device  designs  rely  heavily  on  embedded  software  development,  multiple 
devices  require  the  use  of  a  hub 

9.  RS-644:  A  low  voltage  differential  signal  (LVDS)  equivalent  to  RS-422.  The  LVDS 
signal  is  uses  1.0  and  1.4  volts  as  its  differential  voltage  levels.  These  signals  can  be 
transmitted  over  cables  or  over  a  backplane.  Because  of  this  lower  voltage,  much  less 
power  is  used  and  a  greater  data  rate  can  be  achieved,  up  to  655  Mbps.  Signals  can  be 
bussed  to  achieve  even  higher  data  rates. 

>  Pros  -  High  data  rate  differential,  low  EMI,  low  power 

>  Cons  -  Electrical  specification  only,  must  use  software  for  communications  protocol 

10.  cPCI:  The  Compact  PCI  bus  (cPCI)  follows  the  PCI  bus  electrical  specification  in  a 
Eurocard  form  factor.  Data  packets  of  8,  16,  32  and  64  bits  can  be  transferred  across  the 
bus  at  rates  up  to  66  MHz  (528  MBps).  Data  and  address  signals  are  multiplexed  across 
the  same  lines. 

>  Pros  -  Modular,  industry  standard,  any  device  on  bus  can  become  bus  master 

>  Cons  -  Bulky  form  factor,  voltage  compatibility  is  an  issue  (5V,  3.3V  PCI  versions) 

11.  IEEE  1394:  Also  know  as  Firewire,  a  high  data  rate  point  to  point  interface  mainly  used 
for  the  transmission  of  digital  video  signals.  The  interface  is  capable  of  data  rates 
ranging  from  100  Mbps  up  to  a  maximum  of  4  Gbps.  The  hop  distance  between  each 
node  should  not  exceed  4.5  m  and  the  maximum  number  of  hops  in  a  chain  is  16, 
therefore  the  total  maximum  end-to-end  distance  is  72  m. 
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>  Pros  -  High  data  rate,  industry  standard 

>  Cons  -  Point  to  point  connection  (not  a  multidevice  bus) 


Table  2:  Summary  of  High  Data  Rate  Electrical  Bus  Technologies 


Backplane/ 

Cable 

Central/ 

Distributed 

Num 

Wires 

Max 

Length 

Data  Rate 

Payload 

Fraction 

VME 

Backplane 

Central 

128 

<1  m 

160  Mbps 

99.5  % 

SCSI 

Cable 

Distributed 

68 

6  m 

320  Mbps 

99% 

USB  2.0 

Cable 

Central 

4 

~5  m 

480  Mbps 

99% 

RS-644 

Cable 

Distributed 

2  min 

10-15  m 

655  Mbps 

99% 

cPCI 

Backplane 

Central 

124 

<lm 

1000  Mbps 

99.5  % 

IEEE  1394 

Cable 

Distribute 

4 

4.5m 

4  Gbps 

96% 

After  considering  the  different  high  data  rate  buses  for  SCOUT,  IEEE  803.2  Fast  Ethernet  was 
selected  for  the  following  reasons 

>  High  data  throughput 

>  Well  understood  standard 

>  Commercially  available 

>  Easy  to  interface  to  development  systems 

>  Well  established  technology 

>  Fairly  inexpensive  to  implement 

3.2  Module  Technologies 

12.  AeroAstro  is  developing  miniature  S-Band  and  X-Band  transponders  for  use  on  small 
satellites,  as  shown  in  Figure  13  and  Figure  14.  Flight  S-Band  transmitters  have  been 
delivered  for  use  on  the  Canadian  Space  Agency  MOST  satellite,  and  S-Band  receivers 
have  been  deigned  up  to  the  layout  stage.  There  are  several  proposals  currently  pending 
which  would  involve  delivering  completed  S-Band  transponders.  X-Band  transponders 
for  the  NASA  NMP  ST-5  satellites  have  passed  CDR,  the  prototypes  have  passed  DSN 
compatibility  testing  and  the  flight  models  will  be  completed  in  a  few  months. 

13.  AeroAstro  has  completed  a  study  for  NASA  Wallops  Flight  Facility  (WFF)  which 
investigated  the  feasibility  of  using  the  Globalstar  satellite  constellation  at  1414  km 
altitude  as  a  “virtual  ground  station”  to  provide  more  continuous  communications 
coverage  for  rockets  and  satellites  in  LEO.  Virtual  ground  station  technology  has  the 
potential  to  be  an  effective  enabler  of  rapid,  responsive  and  reliable  communications 
freed  from  the  scheduling  and  availability  constraints  of  the  existing  military  ground 
station  infrastructure.  Two  more  proposals  to  WFF  for  further  study  of  this  concept  are 
pending,  and  at  least  three  other  interested  parties  have  also  been  identified.  The 
Globalstar  solution  is  only  viable  in  the  long  term  if  Globalstar  continues  to  maintain 
their  constellation.  The  INMARSAT  constellation  of  GEO  satellites  has  been  identified 
as  a  potentially  better  virtual  ground  station  solution  than  Globalstar.  This  is  primarily 
because  of  its  wider  coverage  in  LEO  and  at  altitudes  above  the  Globalstar  constellation. 
INMARSAT  offers  low-bandwidth,  low-power  services  that  do  not  require  pointed 
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antennas  which  has  the  potential  to  make  it  equally  attractive  as  Globalstar  for  use  on 
small  satellites.  INMARSAT  has  a  history  of  continuously  maintaining  their 
constellation  by  deploying  upgraded  satellites,  they  are  currently  planning  the 
deployment  of  their  fourth  generation.  A  virtual  ground  station  may  also  be  implemented 
using  laser  communications.  In  this  scenario  each  SCOUT  satellite  is  equipped  with  a 
miniature  gimbaled  low-power  inter-satellite  User  Laser  Transponder  (ULTRA).  The 
SCOUT  satellites  communicate  with  the  ground  through  laser  communications  relay 
satellites  in  GEO  which  are  equipped  with  ULTRAs  as  well  as  higher  power  laser 
transponders  that  are  capable  of  penetrating  Earth’s  atmosphere.  The  advantages  of  this 
scenario  lie  in  frequency  reuse,  more  secure  communications,  much  higher  data  rates  than 
in  RF,  much  better  coverage  than  even  INMARSAT  and  in  avoiding  frequency 
regulations.  AeroAstro  has  outlined  a  conceptual  design  for  the  User  Laser  Transponder 
and  is  in  the  process  of  submitting  a  proposal. 


Figure  13:S-Band  Transmitter  Figure  14:  X-Band  Transponder 


14.  The  Johns  Hopkins  Applied  Physics  Lab  (APL)  has  developed  a  miniature 
NAVSTAR/GPS  receiver  for  satellites  called  GNS-II  which  is  available  for  licensing.  A 
compatible  cross-link  ranging  transponder  is  also  available.  The  GNS-II,  shown  in 
Figure  15,  includes  software  for  on-board  orbit  determination  and  orbit-propagation  as 
well  as  event-based  commanding  for  powerful  operational  autonomy.  Events  include 
specific  times,  node  crossings,  other  locations,  entry/exit  from  south  Atlantic  anomaly, 
eclipse,  daylight  and  ground  station  visibility.  This  receiver  is  currently  only  intended  for 
use  in  LEO  and  does  not  provide  attitude  information.  Future  versions  should  support 
orbit  determination  up  to  altitudes  of  approximately  30  Earth  radii. 
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Figure  15:  GNS-II 


Figure  16:  Miniature  Star  Tracker 


15.  A  novel  method  of  orbit  determination  in  high  Earth  orbits  including  GEO  was  filed  for 
patent  by  ITT  in  1999.  The  method  requires  using  a  UHF  receiver  to  listen  to  the 
AUTONAV  crosslink  and  ranging  signals  between  NAVSTAR/GPS  Block  HR  satellites. 
This  method  of  orbit  determination  requires  initialization  by  another  source  but  may 
nonetheless  be  very  useful.  There  are  currently  eight  Block  HR  satellites  on  orbit  and 
another  twelve  are  planned  for  launch  by  September  2006.  There  is  no  guarantee  that  the 
AUTONAV  system  will  be  enabled. 

16.  AeroAstro  is  currently  under  contract  to  MDA  to  begin  developing  a  low-power,  low- 
accuracy,  low-cost  Miniature  Star  Tracker  shown  in  Figure  16.  This  star  tracker  features 
a  CMOS  imager  instead  of  the  more  traditional  CCD  imager,  the  advantages  of  the 
CMOS  imager  are  that  it  requires  much  less  supporting  electronics  and  is  more  radiation 
tolerant.  This  star  tracker  also  features  pinhole  optics,  the  absence  of  a  lens  and  baffle 
assembly  greatly  reduces  cost  and  volume  of  the  star  tracker  at  the  expense  of 
performance. 

17.  The  Systron  Donner  BEI  Gyrochip  Model  QRS11,  shown  in  Figure  17,  or  future 
derivatives  thereof,  represents  a  suitable  very  low  cost  military  grade  MEMS  angular  rate 
sensor  for  use  in  an  attitude  determination  module.  This  Gyrochip  is  currently  available 
as  a  standard  product. 

18.  The  AeroAstro  Medium  Sun  Sensor,  shown  in  Figure  18,  or  future  derivatives  thereof, 
represents  a  suitable  very  low  cost  space-qualified  sun  sensor  for  use  in  the  attitude 
determination  module.  This  sun  sensor  is  currently  available  as  a  standard  product. 


19.  The  Billingsley  Magnetics  TFM100G2  satellite  magnetometer,  shown  in  Figure  19,  or 
future  derivatives  thereof,  represents  a  suitable  very  low  cost  space  qualified 
magnetometer  for  use  in  the  attitude  determination  module.  This  magnetometer  is 
currently  available  as  a  standard  product. 

20.  The  Microcosm  torque  rods,  shown  in  Figure  20,  and  AeroAstro  torque  rod  driver  boards, 
or  future  derivatives  thereof,  represent  suitable  low  cost  space  qualified  components  for 
use  in  the  magnetic  actuation  module.  These  are  both  currently  available  as  standard 
products,  the  driver  boards  will  be  validated  in  space  on  board  STPSat-1  -2007. 
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Figure  19:  TFM100G2  Magnetometer  Figure  20:  Microcosm  Torque  Rod 

21.  The  Honeywell  Micro- Wheel,  shown  in  Figure  21,  represents  a  suitable  component  for 
use  in  the  micro  wheel  module  for  attitude  actuation,  momentum  dumping,  and  power 
storage.  In  the  Honeywell  design  using  single  crystal  silicon  wafer  wheels  the  angular 
momentum  stored  per  kg  and  per  mA3  is  much  higher  than  what  is  possible  with 
traditional  wheels.  The  integrated  energy  storage  system  is  competitive  with  Lithium-Ion 
battery  cells  even  if  the  multifunctionality  is  not  accounted  for.  When  micro  wheels  are 
arranged  as  shown  in  Figure  9  the  multifunctional  nature  of  the  wheels  does  not  cause 
conflicts  and  even  allows  momentum  to  be  dumped  to  power  instead  of  using  magnetics 
or  thrusters.  This  technology  was  demonstrated  under  an  Air  Force  contract  but  has  not 
yet  been  qualified,  Honeywell  is  currently  pursuing  more  funding  for  the  micro-wheel 
project  through  DARPA. 

22.  AeroAstro  is  currently  under  contract  to  NASA  JSC  to  develop  a  Nitrous  Oxide 
Propulsion  System.  This  is  a  suitable  system  for  use  in  the  divert  as  well  as  the  divert 
and  maneuvering  propulsion  modules.  When  used  in  a  hot-gas  type  system  where  the 
liquid  Nitrous  Oxide  propellant  is  decomposed  within  each  thruster  the  Isp  is  ~  120-  200 
seconds,  which  is  in  between  cold  gas  and  Hydrazine.  An  advantage  over  cold  gas  is  that 
the  propellant  is  stored  in  liquid  form  which  greatly  reduces  volume.  An  advantage  over 
Hydrazine  is  that  the  propellant  is  non-toxic  and  much  safer  and  cheaper  to  work  with. 
The  propellant  is  also  stored  at  much  lower  pressure  than  either  cold  gas  or  hydrazine 
allowing  the  use  of  conformal  or  otherwise  not  rounded  propellant  tanks  for  greatly 
increased  volumetric  efficiency. 

23.  The  Lightband  from  Planetary  Systems  Corporation,  or  future  versions  thereof,  has  been 
identified  as  a  suitable  separation  system  for  the  separation  module,  it  is  shown  in  Figure 
22.  Lightband  is  currently  the  standard  separation  system  for  the  EELV  Secondary 
Payload  Adapter.  Lightband  is  currently  available  as  a  standard  product. 
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Figure  21:  Honeywell  Micro  Wheel  Figure  22:  Lightband  Separation  System 


4.  Summary 

This  document  has  described  conceptual  key  technology  elements  that  are  required  to  implement 
the  SCOUT  architecture.  This  document  has  also  described  actual  existing  and  in-development 
candidate  technologies  that  may  be  capable  of  meeting  the  requirements  if  leveraged.  The 
availability  and  state  of  development  of  the  candidate  technologies  was  assessed.  Many  of  the 
technologies  listed  are  alternatives  to  existing  technologies  which  are  not  mature  enough  in  terms 
of  miniaturization  or  low  cost  to  be  of  use  for  the  SCOUT  architecture. 
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integrating  the  packets  into  the  final  software 

4.5.12  load. 

After  “power  on”  the  component  will  automatical!: 

4.5. 1 3  perform  a  built-in  test. 
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4.5.12  load. 

After  “power  on"  the  component  will  automatical!: 

4.5. 1 3  perform  a  built-in  test. 
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4.6  Deployments 

The  SC  will  accommodate  deployment  of  the 
4.6.1  component  boom. 


Deployment  of  the  comonent  boom  is  a  one-time 
event  that  shall  be  powered,  sensed,  and 
4.6.2  controlled  by  the  SC. 

The  SC  shall  provide  a  deployment  mechanism 
and  a  stowage  cradle  for  the  component  antenna 
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The  SC  processor  shall  provide  a  time  reference 

and  a  time  sync  line  with  a  frequency  of  (per  once 

4.5.3  orbit): 

Within  specified  timeframe,  the  SC  processor 

4.5.4  shall  be  sized  to  store  collected  data  not  32 
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integrating  the  packets  into  the  final  software 

4.5.12  load. 

After  “power  on”  the  component  will  automatically 

4.5. 1 3  perform  a  built-in  test. 
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Aero  Astro 


s3cout 

A  Small  Smart 
Spacecraft  for 
Observation  and 
Utility  Tasks 

Conceptual 
Design  Review 
for  DARPA 

22  MAY  03 


The  following  presentation  was  developed  for  the  final  review  of  the  SCOUT  Phase 
I  SBIR  program.  This  review  was  convened  in  the  form  of  a  Conceptual  Design 
Review  (CoDR).  The  focus  of  a  traditional  CoDR  is  feasibility;  the  goal  of  the 
conceptual  design  process  is  to  work  out  enough  technical  design  details  to  assure 
that  there  are  no  "showstoppers"  in  the  concept.  As  the  conceptual  design  is 
presented  and  discussed  in  the  presentation  that  follows,  it  will  be  seen  that  the  basic 
concept  for  the  SCOUT  microsatellite  architecture  is  sound.  No  significant  issues 
have  been  identified,  although  some  elements  of  the  system  design  are  naturally 
more  mature  than  others. 


Agenda 

SCOUT  Conceptual  Design  Review 

22  MAY  03  -  SRS  Technologies  -  Arlington,  VA 

Time  Duration 

8:00 

0:15 

Introduction 

G.  Cameron 

8:15 

0:20 

Payload  Description 

A.  Rogers 

8:35 

0:20 

Requirements 

S.  Kennison 

8:55 

0:15 

System  Overview 

G.  Cameron 
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0:30 

Mechanical  &  Thermal  Design 

J.  Miller 

9:40 

0:20 

Command  and  Data  Handling 

L.  Jordan 

10:00 

0:15 

Software 

L.  Jordan 

10:15 

0:15 

Power 

L.  Jordan 

10:30 

0:20 

Attitude  Determination  &  Control  System 

A.  Jacobovits 

10:50 

0:15 

Propulsion 

A.  Jacobovits 

11:05 

0:20 

RF  Communications 

G.  Cameron 

11:25 

0:15 

Mission  Operations 

S.  Kennison 

11:40 

0:20 

Integration  and  Test 

A.  Rogers 

12:00 

Adjourn 
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The  Conceptual  Design  Review  was  convened  on  Thursday,  22  MAY  03  at  SRS 
Technologies,  4001  N.  Quincy  Street,  Suite  275,  Arlington,  VA.  The  order  of  the 
presentation  is  shown  on  this  chart.  G.  Cameron  presented  the  material  prepared  by 
S.  Kennison  in  her  absence.  Due  to  time  constraints,  the  material  was  actually 
presented  in  three  hours  rather  than  the  scheduled  four  hours.  Some  of  the  design 
details  that  could  not  be  covered  during  the  presentation  due  to  these  time 
constraints  will  be  discussed  in  greater  depth  in  this  document. 
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Introduction 

Glen  Cameron 

Glen.  Cameron(a)AeroAstro.com 
703-723-9800  Ext.  159 


This  presentation  serves  as  an  introduction  to  the  SCOUT  Program  Conceptual 
Design  Review. 


The  Need  for  SCOUT 


<■  V*  aero  Astro 


•  DARPA  is  developing  RASCAL 
to  fill  a  critical  mission  need  for 
the  US  Military  Space  community 

•  RASCAL  is  intended  to  provide  a 
quick-reaction  launch  capability 
to  orbit  military  payloads  in  days 

•  Launching  a  payload  in  days  is  of 
limited  utility  when  it  takes  years 
to  build  a  typical  Space  Vehicle 

•  SCOUT  is  intended  to  provide  a 
customized  Space  Vehicle  -  built 
to  meet  specific  mission  needs  - 
in  days,  not  years 
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DARPA  is  currently  developing  a  small  launch  vehicle  called  RASCAL  for  the 
express  purpose  of  providing  cheap,  rapid  access  to  space.  RASCAL  is  envisioned 
as  a  launch  vehicle  that  can  insert  a  tactical  or  quick-reaction  military  payload  into 
earth  orbit  on  an  extremely  short  time  scale  -  ultimately  within  hours.  RASCAL  is 
intended  to  create  a  capability  for  the  warfighter  to  utilize  space  power  projection  as 
easily  and  responsively  as  air  power  is  currently  employed. 


Developing  a  capability  like  RASCAL  implies  that  a  tactical  or  quick-reaction 
military  spacecraft  must  be  available  for  launch  on  an  equally  short  timescale.  The 
ability  to  launch  a  payload  within  days  is  of  little  utility  if  a  spacecraft  takes  years  to 
develop.  The  future  of  military  space  will  be  limited  unless  the  warfighter  can 
rapidly  configure  a  spacecraft  to  meet  unique  mission  needs  as  flexibly  as  aircraft 
are  currently  configured.  The  true  utility  of  a  RASCAL-like  capability  can  not  be 
fully  realized  until  such  a  rapid-response,  configurable  spacecraft  is  also  available. 


SCOUT  is  intended  to  provide  exactly  this  type  of  flexible  response  -  to  be  available 
in  days  or  even  hours,  not  years.  SCOUT  will  allow  the  warfighter  to  configure  a 
customized  spacecraft  to  fill  a  unique  need,  assemble  it,  prepare  it  for  launch, 
launch  it,  and  put  it  into  operational  service  rapidly  enough  to  be  compatible  with 
the  rapid  pace  of  modem  warfare. 


Objectives  for  the  SCOUT  System 


To  fully  realize  the  goal  of  a  truly  utilitarian  military  space  capability  that  will 
complement  the  capabilities  of  the  RASCAL  Launch  Vehicle,  SCOUT  must 
meet  the  following  technical  objectives: 

SCOUT  must  be  SMALL  and  LIGHTWEIGHT  to  maximize  utility  within  the 
limited  performance  envelope  of  a  small  launch  vehicle.  It  is  likely  that  any  rapid- 
response  launch  vehicle  (including  RASACAL  derivatives)  will  have  a  modest  mass 
and  orbit  insertion  capability.  To  further  enhance  the  utility  of  the  SCOUT 
architecture,  it  will  be  designed  for  compatibility  with  a  wide  variety  of  potential 
launch  vehicles  as  both  a  primary  and  secondary  payload. 

SCOUT  must  be  LOW  COST  to  assure  that  it  can  be  readily  expended  to  serve  US 
national  security  needs  effectively.  It  is  assumed  that  SCOUT-based  spacecraft 
would  need  to  cost  under  $1M  each  (in  mass  produced  quantities)  to  be  useful  to  US 
forces.  A  parallel  in  the  current  inventory  with  regard  to  the  cost  vs.  capability 
envelope  is  the  Tomahawk  cruise  missile. 

SCOUT  must  provide  a  QUICK  REACTION  capability  to  allow  US  forces  to 
swiftly  respond  to  rapidly  changing  developments  within  an  evolving  battlespace. 

As  recent  conflicts  have  shown,  the  pace  of  modem  warfare  is  constantly 
increasing;  a  response  that  takes  weeks  to  implement  will  be  of  little  or  no  utility  in 
future  engagements. 

SCOUT  must  be  FLEXIBLE  to  permit  a  managable  complement  of  off-the-shelf 
hardware  to  address  a  wide-ranging  set  of  scenarios.  It  is  axiomatic  that  unforeseen 


The  next  four  charts  describe  the  process  that  was  used  to  develop  the  conceptual 
architecture  for  the  SCOUT  system. 

The  development  process  began  by  defining  a  range  of  possible  missions  for  a 
SCOUT-based  space  vehicle.  Having  identified  a  number  of  possible  missions  for 
such  a  vehicle,  these  missions  were  prioritized  on  the  basis  of  sponsor  interest  in 
such  a  capability  and  the  feasibility  of  implementing  a  compliant  version  of 
SCOUT.  This  process  reduced  the  likelihood  that  the  SCOUT  architecture  would  be 
heavily  biased  by  a  mission  that  was  unwanted  or  unlikely  to  be  developed.  The  list 
of  prioritized  potential  missions  was  discussed  with  the  DARPA  Technical  Point  of 
Contact  to  solicit  input  regarding  the  perceived  usefulness  of  the  envisioned 
configurations.  The  input  of  the  sponsor  was  used  to  downselect  to  a  single  mission 
that  served  as  the  basis  for  a  case  study  of  the  SCOUT  architecture.  This  mission 
definition  process  was  documented  in  the  Mission  Definition  Study  that  was 
submitted  to  DARPA  on  07  FEB  03. 

In  parallel  to  the  mission  definition  study,  although  somewhat  lagging  this  process, 
an  assessment  was  conducted  to  evaluate  the  state  of  technologies  that  may  be  key 
to  developing  a  SCOUT  system.  First,  based  upon  the  evolving  mission  definition 
study  and  the  notional  SCOUT  architecture,  a  roster  of  key  technologies  was 
developed  to  provide  a  catalog  of  potentially  useful  capabilities.  Having  identified  a 
"wish  list"  of  technology  needs  for  SCOUT,  the  current  state  of  technological 
advancement  was  surveyed  in  a  number  of  related  technology  disciplines  to  identify 
both  existing  and  projected  near-term  technologies  that  could  potentially  satisfy  any 
of  the  identified  technology  needs.  In  those  cases  where  a  match  was  realized 


Development  Process;  Requirements 


•  Launch  Vehicle  Compatibility  Analysis 

-  Investigate  RASCAL  and  develop  LV  requirements 

-  Survey  other  launch  vehicles  and  develop  LV  requirements 

-  Develop  a  set  of  LV  requirements  for  SCOUT  that  envelopes 
RASCAL  and  a  wide  range  of  alternative  Launch  Vehicles 

•  Requirements  Definition 

-  Analyze  and  develop  a  complete  set  of  mission  requirements 

-  Develop  a  detailed  Mission  Requirements  Matrix 
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A  Launch  Vehicle  Compatibility  Analysis  was  conducted  in  parallel  to  the  Mission 
Study  and  Technology  Study.  In  this  analysis,  the  planned  specifications  for  the 
RASCAL  Launch  Vehicle  were  assessed  and  the  key  limiting  parameters  for 
SCOUT  were  extracted  (e.g.,  envelope,  mass,  quasi-static  loads,  minimum  first 
fundamental  frequency,  etc.).  A  comprehensive  survey  of  other  existing  and  planned 
launch  vehicles  was  conducted  to  gather  similar  data  across  a  wide  range  of 
potential  Launch  Vehicles,  including  capacity  for  both  primary  and  secondary 
payloads.  From  this  compendium  of  LV  capability  and  requirements  data,  a  single 
enveloped  set  of  requirements  was  developed  that  would  allow  SCOUT  to  launch  on 
ALL  of  the  launch  vehicles  in  the  set.  For  a  few  selected  parameters,  a  single  launch 
vehicle  was  significantly  more  limiting  than  all  of  the  other  launch  vehicles.  On  this 
basis,  selected  launch  vehicles  were  excluded  from  the  set  to  provide  for  a  more 
meaningful  (and  less  limiting)  set  of  enveloped  Launch  Vehicle  compatibility 
requirements.  The  resultant  set  of  enveloped  requirements  provides  a  firm  base  for 
developing  a  family  of  SCOUT  spacecraft  that  can  launch  on  any  of  1 8  current  and 
planned  launch  vehicles.  The  results  of  this  Launch  Vehicle  compatibility  analysis 
were  documented  in  a  Launch  Vehicle  Study  submitted  to  DARPA  on  17  APR  03. 


Following  the  Launch  Vehicle  Compatibility  Analysis  and  Mission  Definition 
Study,  an  effort  was  undertaken  to  define  a  set  of  requirements  for  the  SCOUT 
modular  architecture.  The  Launch  Vehicle  capabilities  and  restrictions  formed  a 
core  for  initiating  this  effort.  Other  requirements  were  developed  for  a  number  of 
related  disciplines.  These  requirements  included  both  general  requirements  that 
would  apply  to  all  SCOUT  Space  Vehicles  and  specific  requirements  that  would 
apply  to  only  the  selected  candidate  missions.  These  requirements  were  summarized 


Development  Process:  Conceptual  Design 


•  SCOUT  Conceptual  Design 

-  Develop  an  architecture  that  supports  the  requirements 

-  Focus  on  modular  approaches  to  the  spacecraft  bus  that 
provide  for  evolutionary  development 

-  Identify  modules  common  to  multiple  missions 

-  Identify  mission-specific  modules 

-  Develop  an  overall  SCOUT  mission  design 

-  Develop  a  specific  SCOUT  spacecraft  design  that  meets  these 
mission  requirements 

-  Identify  ongoing  technology  developments  that  can  be 
leveraged  to  enable  or  improve  the  capabilities  of  SCOUT 

-  Perform  a  Conceptual  Design  Review* 

Work  still  to  be  completed* 
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Upon  completion  of  the  Mission  Study,  Technology  Study,  Launch  Vehicle 
Compatibility  Analysis,  and  Requirement  Definition  process,  the  SCOUT  SBIR 
program  moved  into  the  core  task  of  the  Phase  I  effort:  development  of  a  conceptual 
design  for  a  candidate  SCOUT-based  Space  Vehicle. 

Accordingly,  a  concept  for  a  SCOUT-based  microsatellite  was  developed  to  execute 
the  "Escort"  candidate  mission  that  had  been  selected  during  the  mission  study 
process.  This  concept  was  intended  to  incorporate  the  recommended  technologies 
from  the  technology  study  and  be  consistent  with  the  Launch  Vehicle  restrictions 
and  the  requirements  developed. 

This  process  began  with  a  set  of  "brainstorming"  meetings  in  which  the  proposal 
and  white  paper  concepts  for  SCOUT  were  reexamined  in  light  of  the  requirements 
that  had  been  developed.  Many  of  the  original  concepts  were  retained  in  a  general 
sense,  but  all  elements  of  the  design  were  refined.  An  architecture  was  developed 
that  allowed  SCOUT  to  meet  or  exceed  all  of  the  identified  requirements.  These 
early  discussions  focused  on  maintaining  the  flexibility,  scalability,  and 
extensibility  of  SCOUT  by  emphasizing  the  modularity  of  the  system  architecture. 
In  all  cases,  modularity  remained  the  central  pillar  of  the  SCOUT  concept.  With 
these  basic  features  in  place,  the  effort  began  to  focus  on  defining  the  details  of  the 
modules  themselves.  A  rough  concept  was  developed  for  each  of  the  three  missions 
that  had  been  studied.  These  concepts  were  detailed  to  identify  both  common  and 
mission-specific  modules  and  features.  Via  this  process,  the  design  details  of  the 
common  modules  were  further  defined  to  maximize  flexibility  and  utility  of  these 
modules. 

With  a  better  understanding  of  these  common  modules,  the  focus  returned  to  the 
specifics  of  a  SCOUT-based  vehicle  that  could  be  used  to  satisfy  the  Escort  mission 


Development  Process :  Documentation 


•  Final  Report  and  Documentation 

-  Develop  and  deliver  a  final  report  summarizing  all 
investigation,  requirement  development,  and  design  activities* 

-  Develop  recommendations  and  plans  for  Phase  II  including  a 
roadmap  to  develop  SCOUT  to  a  flight-ready  prototype* 

-  Develop  a  commercialization  report  including  a  roadmap  to 
productize  and  commercialize  the  SCOUT  system* 


Work  still  to  be  completed* 
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AeroAstro  completed  the  Conceptual  Design  Review  for  the  SCOUT  Phase  I SBIR 
on  22  MAY  03.  The  remaining  task  is  to  document  the  findings  of  the  SCOUT 
Phase  I  SBIR  in  a  final  report.  In  consultation  with  the  DARPA  sponsor,  it  was 
agreed  that  the  SCOUT  Final  Report  will  consist  of  six  elements:  1)  the  Mission 
Study;  2)  the  Technology  Utilization  Plan;  3)  the  Launch  Vehicle  Analysis;  4)  the 
Requirements  Matrix;  5)  a  fully  annotated  version  of  the  CoDR  viewgraph  package 
(of  which  this  is  a  portion),  and  6)  an  overall  "glue"  document  which  ties  all  of  these 
items  together  into  a  cohesive  report. 


Mission  Selection:  Escort  Vehicle 


Utilizing  this  mission  selection  process,  it 
was  determined  that  SCOUT  would  focus 
its  CoDR  on  an  Escort  vehicle  mission 
A  SCOUT  Escort  vehicle  can  be  used  to: 

-  Facilitate  In-Orbit-Test  activities 

•  Analyze  electromagnetic  emissions 

•  Verify  antenna  patterns 

•  Provide  confirmation  of  deployments, 
alignments,  or  slewing  and  pointing 

-  Provide  intelligence  or  aid  diagnosis  of  a 
malfunctioning  space  vehicle 

•  Employ  sensor  suite  to  characterize  vehicle 

-  Monitor  the  natural  or  induced  local 
environment  in  the  spacecraft’s  vicinity 

•  Assess  potential  contamination  issues 

•  Monitor  threats  from  debris 

•  Detect  presence  of  other  vehicles 
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SCOUT  is  not  a  spacecraft;  SCOUT  is  an  architecture.  It's  difficult  to  meaningfully 
prove  the  utility  of  an  architecture  without  testing  it  in  a  real-world  scenario.  If  cost 
was  not  a  restriction,  SCOUT  would  be  tested  by  building  a  comprehensive 
selection  of  modules  and  testing  them  in  different  combinations  as  solutions  to  real- 
world  problems.  In  the  constrained  environment  of  a  Phase  I  SBIR,  however,  we 
must  demonstrate  the  utility  of  the  SCOUT  architecture  by  measuring  it  (on  paper) 
against  a  single  mission  scenario. 


The  mission  study  conducted  in  Phase  I  proposed  that  SCOUT  be  evaluated  by 
using  it  to  realize  an  "Escort"  mission.  The  plan  was  to  design  a  SCOUT  vehicle  to 
satisfy  the  Escort  mission  needs  using  "standard"  SCOUT  modules  (i.e.,  no  special 
modules  custom- fitted  to  the  Escort  mission  would  be  proposed). 


Escort  is  a  microsatellite  that  flies  in  close  proximity  with  another  satellite  (the 
"primary")  to  evaluate  it's  nature,  behavior,  or  performance.  For  example,  Escort 
can  be  used  to  monitor  and  analyze  electromagnetic  emissions  radiating  from  the 
primary,  either  intentionally  or  unintentionally.  These  emissions  can  be  used  to 
diagnose  problems  or  monitor  the  operating  state  of  the  primary.  Similarly,  Escort 
can  be  used  to  map  out  the  antenna  pattern  of  a  satellite  in  its  as-deployed  state. 
There  are  limitless  applications  for  such  a  spacecraft.  Escort  can  be  used  to 
independently  verify  the  deployment  of  a  boom,  array,  or  antenna,  or  diagnose  an 
improperly  deployed  mechanism.  Escort  can  be  used  to  reconnoiter  an  unknown 
satellite,  or  monitor  the  local  environment  with  respect  to  particles,  fields,  waves,  or 
contamination. 


Concept  of  Operations  Introduction 


>Two  timelines  are  presented: 
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The  lifetime  timeline  is  a  coarse  overview  of  the  expected  major  transitions  of 
SCOUT,  from  launch  through  end  of  mission,  including  potential  hibernation  stints. 


The  Day  in  the  Life  timeline  is  a  more  detailed  account  of  the  anticipated  daily 
operations  scenario,  including  both  space  and  related  ground  activities. 


Mission  Life  TTimeline  ( 


>  Launch  into  target  (GEO)  orbit 
within  1  km  of  primary 

>  Deploy  arrays  and  Detumble 

>  Transition  to  Sun  Pointing  Mode 

>  Perform  ground-based  track  and 
range  collection 

•  Ground-based  ranging  utilized  in 
non-operational  periods 

•  Relative  ranging  utilized  during 
operational  periods 

>  Perform  On-Orbit  Check  Out 


>  Address  Anomalies 

>  SCOUT  declared  healthy 

•  SCOUT  orbit  known 

•  Primary  (target)  orbit  known 

>  SCOUT  is  maneuvered  step-wise 
fashion  toward  the  primary  to  the 
preferred  orbit,  a  stable,  elliptical 
orbit  about  the  primary  at: 

•  250  meter  radial  distance; 

•  500  meter  in-track  distance 
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The  assumptions  incorporated  into  the  coarse  mission  timeline  are:  that  a  launch 
vehicle  will  be  available  that  can  place  SCOUT  into  the  desired  initial  orbit;  within 
1  km  of  the  primary,  and  that  the  best  stable  orbit  is  as  described  in  the  propulsion 
section;  elliptical,  with  in  track  axis  twice  the  length  of  the  radial  axis  about  the 
primary. 

Once  released  from  the  launch  vehicle,  SCOUT  will  be  detumbled  and  the  arrays 
deployed,  then  the  ADCS  mode  will  transition  to  sun  pointing.  Sun  pointing  is 
expected  to  be  the  mode  most  utilized  by  SCOUT. 

SCOUT  will  be  stepped  through  its  on-orbit  check-out  with  ground  ranging  being 
performed  through-out,  laser  ranging  being  performed  upon  check-out  of  the 
payload.  Any  detected  anomalies  will  be  addressed  during  check-out. 

Ground  based  ranging  (absolute  with  respect  to  Earth  Center)  can  be  performed 
while  SCOUT  is  in  sun-pointing  mode  but  relative  (laser)  ranging  will  typically 
require  re-pointing  SCOUT  to  the  primary.  Once  the  relative  ranging  is  completed, 
SCOUT  is  transitioned  back  to  sun  pointing.  Relative  ranging  is  the  standard 
ranging  method,  but  in  the  pre-operational  period  ground  ranging  must  be 
performed  in  order  to  establish  the  absolute  position  with  respect  to  Earth  Center. 
Once  the  absolute  orbit  of  SCOUT  and  its  primary  are  well  known,  the  relative 
ranging  data  (range  between  SCOUT  and  the  primary)  can  be  used  to  update  the 
absolute  orbit.  It  is  this  adjusted  absolute  orbit  ephemeris  that  will  be  used  to 
calculate  orbital  maneuvers,  including  the  step-in  to  the  preferred  orbit  about  the 
primary. 


Mission  Life  Timeline  II 


>  Normal  Operations  Begin 

•  Details  captured  in  Day  in  the  Life  Timeline 

>SCOUT  may  be  placed  in  Hibernation  Mode  at  any  time 

•  Slow  spin,  sun  pointed 

•  SCOUT  powered  down  except  critical  loads 

•  Once  per  hour,  switch  transmitter  on: 

-  Perform  ranging 

-  Collect  telemetry 

>Total  mission  life  is  one  year  including  hibernation 

>  Active  mission  life  is  135  days  (based  on  propellant  budget) 

> Post-mission,  SCOUT  is  placed  in  super-synchronous  orbit 
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Hibernation  mode  -  the  slow  spin  provides  pointing  stability.  Should  SCOUT  be 
left  in  hibernation  mode  for  extended  periods,  the  relative  position  of  Sun  to 
SCOUT  orbit  would  change  such  that  it  would  be  necessary  to  use  the  propulsion 
system  to  realign  the  SCOUT  spin  axis  to  the  Sun.  Otherwise,  hibernation  is 
basically  a  quiescent  mode  with  minimum  thermal  control,  most  loads  off  except 
the  receiver,  flight  computer  and  the  transmitter  during  (ground)  ranging  only. 


Operational  Restrictions 


These  limits  define  mass  storage  requirements:  35  Mbytes 

Mass  storage  flows  down  to  payload  data  collection  operations:  1  hour  collection 


Spacecraft  operations  are  dominated  by  power  concerns.  The  main  limiter  is 
spacecraft  power,  though  in  the  case  of  SCOUT,  some  power  restrictions  exist  on 
the  ground,  as  well,  in  order  to  keep  SCOUT  field-operable. 

Transmitter  power  combined  with  antenna  size  define  the  link  budget  limitations; 
this,  in  turn,  identifies  the  maximum  downlink  data  rate  achievable.  The  spacecraft 
power  budget  defines  how  long  the  transmitter  can  remain  on  before  the  battery 
depth  of  discharge  exceeds  safe  limits.  Thus,  transmitter  on-time  and  data  rate 
define  how  much  data  can  be  downloaded  from  the  spacecraft  on  a  routine  basis. 
This  amount  of  data  establishes  the  data  storage  requirement  (here,  35  Mbytes), 
which  sets  the  limit  on  how  much  data  can  be  collected.  Thus,  available  power 
ultimately  defines  payload  operations. 


Day  in  the  Life  Description 


>To  operate  within  the  identified  restrictions,  the  daily 
operational  cycle  has  been  defined  as: 

•  Three  cycles  per  day 

•  8  hours  per  cycle 

-  1  hour  of  payload  activity 

-  5  hours  of  download  and  battery  recharge 

-  2  hours  for  maneuver  planning,  execution,  and  range  data  collection 

>Delta  V  budget  supports  one  100  meter  maneuver/day 

>When  possible,  maneuvers  will  be  performed  on-node  for 
efficiency,  although  this  is  probably  not  necessary  due  to 
the  small  daily  orbital  changes  anticipated 

>  Ranging  under  normal  operations  is  relative  (optical) 
ranging,  not  ground  based  (tone)  ranging 
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The  Delta  V  budget  can  be  broken  out  as  is  convenient  -  for  instance,  as  two  50 
meter  maneuvers  or  (for  less  than  100  meters  total)  three  20  meter  maneuvers. 


Day  in  the  Life  Timeline  I:  Space  Segment 


>  SCOUT  is  slewed  from  sun 
pointing  to  primary  pointing 

>  Relative  ranging  continues  to  be 
performed  once  per  hour 
(slew  to  primary  as  required) 

>  P/L  and  S/C  health  maintenance 
commands  are  uploaded 

•  Maneuver  plans  are  stored  for 
later  execution 

>  Payload  operations  are 
performed  for  up  to  one  hour 

•  Payload  data  collection  is  limited 
to  35  MB;  any  instrument  may  be 
used  as  desired  within  that  limit. 
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>  Payload  is  powered  down 

>  SCOUT  is  slewed  to  sun  pointing 

>  Transmitter  is  powered  on 

>  Battery  recharge  is  initiated 

>  Telemetry  and  P/L  data  are 
downloaded  (~  2  hours) 

>  Stored  maneuver  commands  are 
executed 


Page  7 


This  is  a  step  by  step  description  of  the  space  segment  portion  of  one  8  hour 
operations  cycle. 

Note  that  for  relative  ranging,  SCOUT  must  first  be  slewed  such  that  the  laser  range 
finder  is  pointing  at  the  primary  and  the  laser  range  finder  must  be  switched  on; 
range  data  is  delivered  to  the  on-board  storage  device. 

The  payload  and  spacecraft  health  and  maneuver  commands  were  generated  during 
the  previous  8  hour  cycle. 

The  battery  recharge  is  implemented  during  the  download;  power  subsystem 
analysis  shows  this  is  feasible.  Two  hours  of  download  (transmitter  on  time)  with 
battery  charging  are  followed  by  up  to  three  hours  of  battery  recharge  with 
transmitter  off. 


The  performance  and  topology  of  the  RF  Communications  Transponder  module  is 
summarized  in  this  presentation. 


Requirements 


•  Uplink 

-  Telemetry  Types:  CMD,  Software  Upload,  4-tone  Ranging 

-  Data  Rates:  At  least  2  kbps 

-  Protocols:  CCSDS  Telecommand  Packets,  COP-1 

-  Link  Margins:  6  dB  at  GEO 

•  Downlink 

-  Telemetry  Types:  P/L  TLM,  Housekeeping  TLM,  4-tone  Ranging 

-  Data  Rates:  At  least  76.8  kbps 

-  Protocols:  CCSDS  Telemetry  Packets 

-  Link  Margins:  3  dB  at  GEO 
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The  requirements  for  the  SCOUT  Escort  Communications  subsystem  are  relatively 
simple  at  this  conceptual  level  of  the  design  process. 


The  uplink  must  be  capable  of  communicating  commands,  software  uploads,  and 
ranging  tones  from  the  ground  station  to  the  SCOUT  vehicle.  The  minimum 
acceptable  data  rate  for  this  task  is  2  kbps.  It  is  assumed  that  the  uplink  command 
protocols  would  be  packetized,  most  likely  using  CCSDS  standards.  If  CCSDS  is 
selected,  it  is  assumed  that  some  sort  of  Command  Operations  Protocol  would  be 
used,  probably  the  COP-1  protocol  from  CCSDS.  Finally,  it  is  expected  that  the 
uplink  data  communications  should  have  a  link  margin  of  at  least  6  dB  in 
accordance  with  Good  Engineering  Practice. 


The  downlink  must  be  capable  of  communicating  payload  or  "mission"  telemetry, 
housekeeping  telemetry,  and  return  link  ranging  tones  from  the  SCOUT  vehicle  to 
the  ground  station.  The  minimum  acceptable  data  rate  for  this  task  is  76.8  kbps.  It  is 
assumed  that  the  downlink  telemetry  would  be  packetized,  most  likely  using 
CCSDS  standards.  Finally,  it  is  expected  that  the  downlink  data  communications 
should  have  a  link  margin  of  at  least  3  dB  in  accordance  with  Good  Engineering 
Practices. 


Orbit  Parameters 

Periqee 

•  Assumes  GEO  Orbit 

hp  -  Periqee  Alt  (km) 

35800.00 

Rp  -  Periqee  Radius  (km) 

42178.14 

Rp  -  Periqee  Radius  (Re) 

6.61 

•  Assumes  minimum  Earth 

Apoqee 

ha  -  Apoqee  Alt.  (km) 

35800.00 

Station  Look  Angle  of  1 5° 

Ra  -  Apoqee  Radius  (km) 

42178.14 

Ra  -  Apoqee  Radius  (Re) 

6.61 

Period 

T  -  Period  (sec) 

86206.91 

T  -  Period  (min) 

1436.78 

T  -  Period  (hours) 

23.95 

T  -  Period  (days) 

1.00 

Orbital  Elements 

a  -  Semi  Major  Axis  (km) 

42178.14 

e  -  Eccentricity 

0.00 

i  -  Inclination  (deq) 

0.00 

w  -  Arqument  of  Periqee  (deq) 

0.00 

W-RAAN  (deq) 

0.00 

E  -  Enerqy  (kmA2/sA2) 

-4.72520 

Ground  Station  Passes 

Maximum  Slant  Ranqe  (km) 

40074.99 

Maximum  Earth  Solid  Anqle  (deq) 

66.60 

Subsatellite  Arc  (deq) 

16.79808 

Minimum  ES  Look  Anqle  (deq) 

15 

Constants 

Re  -  Earth  Radius  (km) 

6378.14 

GM  or  m  (kmA3/sA2) 

398600.50 

q  (m/sA2) 

9.80 

<?\> 
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This  chart  summarizes  the  orbit  parameters  for  the  SCOUT  Escort  mission,  which  is 
expected  to  operate  in  Geostationary  Earth  Orbit  (GEO).  As  shown  in  this  chart,  this 
is  approximated  as  an  orbit  with  an  altitude  of  35,800  km,  an  eccentricity  of  zero, 
and  an  inclination  of  zero. 


The  key  parameter  in  this  chart  is  the  calculated  maximum  slant  range  of  40,075  km 
given  an  expected  minimum  Earth  Station  look  angle  of  15  degrees.  This  slant  range 
is  carried  forward  to  the  link  budgets  shown  on  the  next  two  pages. 


Uplink  Budget 


Ground  Station  Network 

USN 

USN 

Ground  Station  Location 

North  Pole,  AK 

Sturup,  Sweden 

IldMIM-kHMIl.liItJUihlMiiMUM 

13m 

8m 

| Ground  Station  EIRP  (dBW)  |  68.00  |  69.00 


2.10 

2.10 

1  sM  ill  1-1  iN  nTiTnWHflHMMKi 

40074.99 

40074.99 

-190.94 

Absorption  Losses  (dB) 

-1.50 

-1.50 

Polarization  Loss  (dB) 

-0.25 

-1.00 

-1.00 

Redeved  Power  (dBW) 

-124.69 

Redeve  Antenna  Gain  (dB) 

0.00 

0.00 

-1.00 

-1.00 

-0.80 

-0.80 

Received  Signal  (dBm) 

-97.49 

-96.49 

iRequired  Signal  Strength  (dBm)  |  -105.00  |  -105.00  | 

iLink  Margin  -  No  Coding  (dB)  |  7.51  I  8.51  I 


Universal  Space  Network 
Stations  at  North  Pole,  AK  and 
Sturup  Sweden  used: 

•  This  assumption  is  made 
because  these  stations 
represent  Earth  Stations 
with  real  performance  at 
S-Band  (for  uplink)  and 
X-Band  (for  downlink) 

This  shows  an  uplink  margin  of 
at  least  7.5  dB  (vs.  6  dB  need) 
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This  chart  shows  a  communications  Link  Budget  for  the  Uplink  to  the  SCOUT 
Escort  vehicle  from  two  different  Earth  Stations.  This  link  budget  does  not  imply 
that  the  Universal  Space  Network  Earth  Stations  at  North  Pole,  Alaska  and  Sturup, 
Sweden  would  necessarily  be  used  to  communicate  with  SCOUT;  these  two  Earth 
Stations  were  selected  to  provide  typical  performance  numbers  for  Earth  Stations.  It 
is  envisioned  that  SCOUT  will  use  S-Band  for  uplink  communications  and  X-Band 
for  downlink  communications;  these  two  stations  both  support  S-Band  Uplink  and 
X-Bank  Downlink  operations,  making  them  good  analogs  for  an  objective  system. 


Using  the  stated  EIRP  of  these  two  Earth  Stations  at  S-Band  in  combination  with 
the  40,075  km  path  length  leads  to  a  minimum  received  power  of -125.7  dBW  at  the 
spacecraft.  Combined  with  the  antenna  gain  and  feed  loss  of  the  spacecraft,  this 
leads  to  a  minimum  input  power  to  the  S-Band  receiver  of  -97.5  dBm.  This  receiver 
is  expected  to  deliver  a  Bit  Error  Rate  of  IE-6  at  an  input  power  level  of  -105  dBm, 
leading  to  an  uplink  margin  of  at  least  7.5  dB  for  this  link,  which  is  1.5  dB  in  excess 
of  the  required  6  dB  link  margin. 


Downlink  Budget 


Ground  Station  Network 

USN 

USN 

Ground  Station  Location 

North  Pole.  AK 

Stump,  Sweden 

Ground  Station  Dish  Diameter 

13m 

8m 

Transmitter  Output  Power  (W) 

1.50 

1.50 

Transmitter  Output  Power  (dBW) 

1.76 

1.76 

Feed  Losses  (dB) 

-0.50 

-0.50 

Transmit  Antenna  Gain  (dB) 

0.00 

0.00 

EIRP  (dBW) 

1.26 

1.26 

Siqnal  Frequency  (GHz) 

8.40 

8.40 

Path  Length  (km) 

40074.99 

40074.99 

Path  Loss  (dB) 

-202.98 

-202.98 

Absorption  Losses  (dB) 

-1.50 

-1.50 

Polarization  Loss  (dB) 

-0.25 

-0.25 

Pointinq  Loss  (dB) 

-1.00 

-1.00 

Recieved  Power  (dBW) 

-204.47 

-204.47 

Recleve  System  G/T  (dB/K) 

37.50 

32.00 

Boltzmann’s  Constant  (dBW/Hz-K) 

-228.60 

-228.60 

Received  C/No  (dB/Hz) 

61.63 

56.13 

Bit  Rate  (kbps) 

76.80 

76.80 

Bit  Rate  (dB-Hz) 

48.85 

48.85 

Recieved  Eb/No  (dB) 

12.77 

7.27 

|  Required  Eb/No  -  No  Coding  (dB)  I  10.50  |  10.50  | 

[Link  Margin  -  No  Coding  (dB)  |  Z27  f  -3  23  | 


Codinq  Gain  (dB) 

7.50  |  7.50 

Required  Eb/No  -  With  Coding  (dB) 

3.00  |  3.00 

{Link  Margin -With  Coding  (dB)  |  9-77  1  4.27  | 
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•  Universal  Space  Network 
Stations  at  North  Pole,  AK  and 
Sturup  Sweden  used: 

•  This  assumption  is  made 
because  these  stations 
represent  Earth  Stations 
with  real  performance  at 
S-Band  (for  uplink)  and 
X-Band  (for  downlink) 

•  Assumes  concatenated 
Rate-1 12  Convolutional  plus 
Reed-Solomon  (255,223) 
(consistent  with  CCSDS) 

•  This  shows  a  downlink  margin  of 
at  least  4.3  dB  (vs.  3  dB  need) 
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This  chart  shows  a  communications  Link  Budget  for  the  Downlink  from  the 
SCOUT  Escort  vehicle  to  two  different  Earth  Stations.  Again,  this  link  budget  does 
not  imply  that  the  Universal  Space  Network  Earth  Stations  at  North  Pole,  Alaska 
and  Sturup,  Sweden  would  necessarily  be  used  to  communicate  with  SCOUT;  these 
two  Earth  Stations  were  selected  to  provide  typical  performance  numbers  for  Earth 
Stations.  It  is  envisioned  that  SCOUT  will  use  S-Band  for  uplink  communications 
and  X-Band  for  downlink  communications;  these  two  stations  both  support  S-Band 
Uplink  and  X-Bank  Downlink  operations,  making  them  good  analogs  for  an 
objective  system. 


Using  the  nominal  1.5  watt  output  power  from  the  downlink  transmitter,  combined 
with  the  anticipated  worst  case  feed  loss  and  antenna  gain,  it  is  expected  that  the 
SCOUT  Escort  vehicle  will  produce  a  minimum  EIRP  of  1.26  dBW.  Combining  this 
EIRP  with  the  40,075  km  slant  range  and  8.40  GHz  transmit  frequency,  the  worst 
case  received  power  is  expected  to  be  -204.5  dBW  at  the  Earth  Station.  Combined 
with  the  USN  Earth  Station  G/T  performance  numbers  and  a  data  rate  of  76.8  kbps, 
this  yields  a  minimum  Eb/No  of  7.3  dB.  For  a  link  that  uses  no  coding,  10.5  dB  is 
required  to  achieve  the  necessary  IE-6  Bit  Error  Rate.  This  means  that  coding  must 
be  used  to  achieve  the  desired  Bit  Error  Rate.  A  rate- 1/2  constraint-length  K=7 
convolutional  encoder  used  concurrently  with  an  interleaved  Reed-Solomon 
(255,223)  encoder  produces  a  coding  gain  of  7.5  dB.  If  implemented  on  this  link, 
this  coding  brings  the  anticipated  worst-case  link  margin  up  to  4.3  dB,  which  is  1.3 
dB  in  excess  of  the  required  3  dB  link  margin. 


Block  Diagram 


Aero  Astro 
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This  graphic  depicts  a  block  diagram  of  the  SCOUT  Communications  Transponder 
module  used  for  the  SCOUT  Escort  Vehicle.  The  S-Band  uplink  circuitry  is  shown 
in  red,  the  X-Band  downlink  circuitry  is  shown  in  blue,  and  the  common 
uplink/downlink  electronics  are  shown  in  green. 


The  S-Band  uplink  signal  is  received  by  a  tuned  S-band  patch  antenna  and  then 
(probably)  filtered  by  a  small,  low-loss  X-band  reject  filter.  This  filter  is  intended  to 
keep  coupled  energy  from  the  X-Band  downlink  out  of  the  uplink  circuitry  where  it 
could  possibly  saturate  the  Low  Noise  Amplifier  in  the  receiver  Front  End.  It  is 
likely  that  this  filter  will  not  be  needed.  This  command  receiver  demodulates  the 
uplink  command  packets  and  forwards  the  packets  to  the  SCOUT  Core  Electronics 
Block,  which  transmits  them  via  the  SCOUT  Backbone  bus  to  the  rest  of  the 
spacecraft  electronics.  The  reciever  also  recovers  the  ranging  tones  and  sends  them 
over  to  the  downlink  transmitter. 


The  X-Band  downlink  data  is  sent  to  the  communications  transponder  module  over 
the  high-speed  Ethernet  bus  in  the  SCOUT  Backbone.  This  data  is  forwarded  to  the 
downlink  circuitry  where  it  is  interleaved,  Reed-Solomon  encoded,  Convolutionally 
encoded,  combined  with  the  ranging  tone  subcarrier,  and  then  modulated  onto  an  X- 
Band  carrier.  The  modulated  carrier  is  transmitted  at  1.5  watts  RE  power  from  a 
tuned  X-Band  patch  antenna. 


Module  Configuration 


This  graphic  is  intended  to  demonstrate  the  feasibility  of  packaging  the  S-Band/X- 
Band  transponder  into  a  2-cm  high  SCOUT  module.  The  enclosures  shown  within 
this  module  are  actual-size  models  of  the  transmitter,  receiver,  oscillator,  and 
diplexer  (filter)  used  in  the  AeroAstro  NMRF  X-Band  transponder  being  developed 
for  NASA's  Goddard  Space  Flight  Center.  From  this  CAD  model,  it  is  apparent  that 
packaging  the  S-Band/X-Band  transponder  into  a  2-cm  high  SCOUT  module  should 
be  relatively  straightforward.  The  rectangles  on  the  side  of  the  module  represent  the 
two  "patch"  antennas  that  would  be  used  to  transmit  and  receive  the  electromagnetic 
signals. 


S-Band  Uplink  Receiver 


Receiver  Features: 

•  The  receiver  is  programmable  over 
the  S-Band  range  (2025-2120  MHz) 

•  The  analog  transponder  channel 
enables  non-coherent  tone  ranging 

•  Extremely  small  and  low  mass 

•  Intended  for  use  with  CCSDS- 
compatible  ground  stations 

•  Utilizes  COTS  technology  for 
maximum  performance 

•  Includes  Latch-up  Detection  and 
Mitigation  circuitry  (LDM) 

•  No  Diplexer  Required 

•  RX  frequency  set  by  embedded 
micro-controllers,  eliminating  need 
for  customized  crystals 


Receiver  Specifications: 
Modulation  Type:  BPSK 

DC  Input  Power:  <  4W 

Freq.  Range:  2025  -  2120  MHz 

Data  Rate:  1 ,  2,  or  4  kbps 

Sensitivity:  -105  dBm 

(BER=1e-6)  @  2  kbps 
Lockup  time:  <  5  seconds 

Noise  Figure:  <  9dB  (with  TX  on) 
Ranging:  4-Tone,  non-coherent 

Data  Interface:  RS-422 

Clock  Interface:  RS-422 

RSSI  telemetry:  0-5V  analog 
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This  chart  summarizes  the  anticipated  characteristics  of  the  S-Band  uplink  receiver. 
This  conceptual  design  is  derived  from  another  AeroAstro  design  and  is  considered 
relatively  low-risk.  The  Bit  Error  Rate  performance,  Sensitivity,  and  Noise  Figure 
are  considered  challenging,  but  not  stressing.  The  RS-422  Data  and  Clock  interfaces 
would  easily  communicate  with  the  SCOUT  Common  Electronics  Block,  as  would 
the  analog  telemetry  signals. 


X-Band  Downlink  Transmitter 


Based  on  an  AeroAstro  Transponder 
developed  for  NASA;  the  first  three  X-Band 
Transponders  will  be  flown  on  the  NASA 
New  Millennium  Program’s  ST5  mission 

Frequencies:  8.40  to  8.50  GHz 
Modulation  Method:  BPSK  or  QPSK 
Data  Rates:  10  to  750  kbps 
RF  Output:  1 .5  W  transmit  power 
Power  Consumption:  15  W  transmit 
Volume:  6  cm  x  9  cm  x  1  cm 
Mass:  0.200  kg 

Temperature:  -20  to  40°C  operational, 

-40  to  50°C  survival 


Transponder  Prototype 


AeroAstro 
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This  is  a  photo  of  the  existing  NMRF  X-Band  Downlink  Transmitter.  This  design 
can  be  directly  adapted  to  SCOUT  with  very  little  difficulty. 


Patch  Antennas 


Representative  Antenna  Characteristics: 

•  Center  frequency:  1615  MHz  ±  5  MHz 

•  Left  hand  circular  polarization 

•  VSWR:  2:1  max  (25  MHz  bandwidth) 

•  Gain  at  zenith:  3  dBic  min 

•  Axial  Ratio  at  zenith:  3  dB  max 

•  Omnidirectional  in  azimuth 

•  Half-power  beamwidth:  1 00° 

•  Directivity  variation  <5  dB 


Dimensions 
for  L-Band 
Patch  Antenna 
shown  at  right 


2.36 

. 

0 

'  90 

90* 

\  25* 
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Patch  antennas  have  been  used  on  spacecraft  for  years;  the  only  challenge  for  these 
S-  and  X-band  patch  antennas  would  be  their  relatively  small  size.  The  antennas 
shown  above  were  developed  for  AeroAstro  by  Spectrum  Microwave  and  represent 
a  very  small  size  for  an  L-Band  patch  antenna.  Note  that  most  (approximately  2/3) 
of  the  2.36  inch  antenna  shown  above  is  the  ground  plane  surrounding  the  antenna 
proper.  This  makes  the  antenna  itself  about  0.8  inches,  or  2  cm  wide.  Using  this 
same  technology,  an  S-  and  X-Band  antenna  would  be  even  smaller.  It  is  not 
considered  problematic  to  develop  these  higher-frequency  antennas  to  fit  on  the  side 
of  a  2  cm  high  SCOUT  module,  assuming  that  the  module  itself  (which  is 
aluminum)  can  act  as  the  ground  plane  for  these  antennas.  Again,  this  is  considered 
a  relatively  low-risk  development. 


RF  Communications  Module  Power 


•  Based  upon  power  consumption  for  the  NMRF  Engineering 
Model,  the  SCOUT  RF  Comm  Module  can  be  expected  to 
exhibit  approximately  the  following  power  consumption: 

-  Receiver  Only:  2.3  to  3  watts  (at  6.5  to  8.4  VDC,  regulated) 

-  Transmitter  Only  (No  PA):  2.3  to  3  watts  (at  6.5  to  8.4  VDC) 

-  PA  Only:  9  watts  (at  2W  RF  output  power  -  capable  of  4W  RF) 

-  DC/DC  Converter  Efficiency:  80% 

•  Total  Power  Consumption: 

-  Receiver:  3.75  watts 

-  Transmitter:  11.25  watts 

•  Power  while  transmitting:  15  watts 

•  The  power  reserved  in  the  budget  is  very  conservative 
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Finally,  This  chart  makes  a  comment  on  the  power  budget  used  for  the  SCOUT 
Escort  Vehicle.  Referring  to  the  power  budget  in  section  08,  it  is  seen  that  this 
budget  assumes  a  communications  transponder  module  that  consumes  49.2  watts. 
This  power  estimate  is  based  on  an  early  power  estimate  using  an  older-technology 
transmitter.  The  NMRF  X-Band  Transponder  Engineering  Model  uses  3  watts  of 
power  for  its  receiver  and  9  watts  of  power  for  its  transmitter  (while  transmitting  2 
watts  RF).  Using  an  80%  efficient  DC/DC  converter,  the  actual  power  consumption 
would  be  3.75  and  1 1.25  watts  for  the  receiver  and  transmitter,  respectively.  This 
adds  up  to  a  combined  SCOUT  communications  transponder  module  power 
consumption  of  15  watts,  about  30%  of  the  49.2  watts  carried  in  the  power  budget. 
This  savings  translates  to  an  orbit  average  power  savings  of  8.2  watts,  however,  as  a 
24%  duty  cycle  is  assumed  for  the  transmitter. 


VS 
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Propulsion  Block  Diagram 


Valves  &  Electronics 
Are  Immersed  in  Propellant 


Valve  Key 
Isolation 


Isolation  Plenum 
Valve  Control 
Valve 

When  active,  plenum  control  electronics 
open  and  close  plenum  valve  to  ensure 
constant  supply  of  gas  in  plenum  based  on 
sensor  feed  back. 


Dual  Thruster 
Quads 


*  v 
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We  begin  the  discussion  of  the  SCOUT  Escort  propulsion  system  with  a  functional 
block  diagram. 

N20  propellant  enters  a  micro  plenum  chamber  within  the  tank  through  a  valve. 

The  pressure  and  temperature  within  the  plenum  is  controlled  through  a  closed 
feedback  loop  such  that  all  the  propellant  inside  it  transforms  to  gaseous  state. 
MEMS  (Micro  Electro-Mechanical  Systems)  valves  are  used  thourghout  the  system 
-  they  are  immersed  in  the  propellant  along  with  an  electronics  driver  board  on 
which  the  propellant  feed  system  is  also  built.  The  feed  system  channels  propellant 
from  the  plenum  to  individual  hot  gas  thrusters  which  are  arranged  in  two  quads. 

Several  other  thermodynamic  configurations  for  N20  have  been  under  investigation 
by  AeroAstro,  these  include  cold  gas,  cold  gas  with  a  vaporizer,  and  warm  gas. 
These  alternative  configurations  were  not  selected  by  AeroAstro  for  further 
development  because  of  their  reduced  performance  and  mostly  equivalent  risk. 
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To  provide  a  high  level  of  inspection  capability  Escort  needs  to  be  highly 
maneuverable  in  both  attitude  and  translation.  In  order  to  provide  fully  uncoupled 
six-degree-of-freedom  control,  at  a  minimum,  a  classic  twelve-thruster  topology 
should  be  used.  At  first  it  was  desired  to  keep  the  tanks  and  all  12  thrusters  in  the 
same  module  for  integration  ease.  However,  to  keep  the  thruster  moment  arms 
longer,  and  to  provide  more  flexibility  in  the  center  of  mass  location  when  stacking 
modules  for  different  types  of  SCOUT  satellites,  it  was  decided  to  place  the 
thrusters  on  separate  modules  at  opposite  ends  of  the  stack.  In  order  to  avoid  the 
complexities  of  feeding  propellant  through  different  modules  it  was  decided  that  the 
thruster  module  on  each  end  of  the  stack  should  be  equipped  with  its  own  fuel  tank 
and  would  not  share  propellant  with  the  other  module.  An  external  tube  between 
the  two  modules  was  contemplated  and  not  ruled  out,  but  it  could  lead  to 
undesirable  thermal  pumping  of  the  fuel. 

The  thruster-clusters  at  the  two  ends  of  the  stack  need  to  have  somewhat  different 
topologies,  in  order  to  meet  the  requirement  for  different  topologies  but  also  keep 
the  two  modules  identical,  the  three  different  configurations  shown  were 
contemplated.  The  selected  configuration  was  chosen  because  it  did  not  involve  the 
use  of  a  separate  module  for  rotating  or  flipping  the  propulsion  module  at  one  end  of 
the  stack.  The  one  complexity  of  the  selected  configuration  is  that  the  MUGSE 
needs  to  make  sure  that  the  propulsion  modules  were  oriented  correctly  in  stacking, 
since  it  is  possible  to  orient  them  two  different  ways.  A  fool  proof  method  of  doing 
this  was  not  settled  upon,  the  current  baseline  recommendation  is  place  the  onus  on 
the  human  in  the  loop. 


Proximity  Maneuvering  Propulsion  Module 


The  diagrams  above  show  some  mechanical  features  of  the  maneuvering  propulsion 
module.  Unlike  other  modules  that  are  not  pressurized,  this  one  is  a  welded 
titanium  pressure  vessel.  Titanium  is  a  standard  working  material  commonly  used 
by  VACCO  and  it  should  pose  no  problem  for  them  to  manufacture.  In  order  to 
provide  extra  structural  stiffness  there  are  several  internal  support  posts  within  the 
module  that  effectively  prevent  it  from  bulging  outwards  when  under  pressure.  The 
thrusters  quads  are  cylindrical  ceramic  blocks  with  precisely  machined  combustion 
chambers  and  nozzles  drilled  into  them.  Because  the  combustion  temperature  of 
N20  is  extremely  high  some  titanium  may  be  used  around  the  nozzles  for  additional 
heat  shielding. 

The  two  connectors  on  one  side  of  the  module  are  clearly  visible.  A  typical  module 
should  only  have  one  such  connector  but  the  Maneuvering  Propulsion  module  has 
two  because  it  needs  to  be  stacked  in  different  orientations  at  different  ends  of  the 
stack. 


AV  and  Propellant  Budgets 


>  Additional  Major  Assumptions 

•  Thrust:  0.1  N  (Based  on  Chamber) 

-  Independent  of  Isp  or  Cold  vs.  Hot 

-  Could  be  reduced  if  need  to  tweak  mission 

•  Specific  Impulse:  120  sec  (Worst  Case) 

-  Could  be  up  to  160  sec  (Cold  N20  =  60  sec) 

•  Orbit  Limit  Cycle:  2560  sec  (10  *  ADCS) 

•  Orbit  Limit  Cycle  AV  Margin:  25% 

•  Propellant  Mass  Margin:  30% 


Mass  Source 

Mass  (kg) 

Dry  Structure  (25%  margin) 

60 

Impulse  (Attitude)  Propellant 

4.135 

AV  Propellant 

2.00 

Margin  Propellant 

1.84 

Pressurant  Propellant 

0.42 

Total 

68.4 

AV  Source 

AV  (m/s) 

Initial  Separation 

0.0073 

Radial  &  In-Track  Maneuvering 

0.4345 

Cross-Track  Maneuvering 

0.870 

North-South  Station  Keeping 

15.0 

East-West  Station  Keeping 

0.6 

Orbit  Limit  Cycle 

3.045 

Disposal  to  Super-GEO 

10 

Thruster  Offset  Disturbance 

6.23 

Total 

36.2 

•  One  100  m  Amplitude  Radial  and 
Cross-Track  Maneuver  Per  Day 

•  4  cm  Effective  Thruster  Offset 

-  Center  of  Mass  Uncertainty 

-  Thruster  Offset  Uncertainty 

-  Thruster  Misalignment  Uncertainty 

-  Thrust  Balancing  Uncertainty 
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The  thrust  in  a  N20  thruster  is  set  by  adjusting  the  chamber  geometry;  a  0.1  N  thurst 
level  was  selected.  The  minimum  on-time  was  selected  to  be  long  enough  for  the  gas 
to  fully  ignite,  thereby  allowing  a  higher  Isp.  The  resulting  propellant  efficiency  was 
found  to  be  greater  than  what  could  be  achieved  by  reducing  the  on-time  and 
accepting  a  lower  Isp  closer  to  that  of  cold  gas,  due  to  incomplete  combustion 

A  detailed  AV  budget  was  assembled  that  included  the  entries  from  the  table  on  the 
right.  The  maneuvering  (relative  to  the  primary)  budget  allowed  for  a  single  100 
meter  amplitude  radial  maneuver  per  day  and  also  a  single  100  meter  amplitude 
cross-track  maneuver  per  day.  The  station-keeping  budgets  were  conservative  and 
assumed  unusually  tight  orbit  control.  The  thruster  offset  was  conservatively  large  to 
also  include  the  effects  of  center  of  mass  uncertainty,  thruster  misalignment 
uncertainty  and  thrust  balancing  uncertainty.  Some  propellant  margin  was  allocated 
specifically  to  the  orbit  limit  cycle  AV  because  that  was  deemed  to  be  a  particularly 
uncertain  estimate. 

The  overall  propellant  budget  was  assembled  in  the  table  on  the  left,  it  includes 
propellant  used  for  attitude  control  described  in  the  previous  section  as  well  as 
propellant  used  for  AV.  Propellant  margin  was  allocated  specifically  to  both  attitude 
control  and  AV  at  the  same  time  in  the  form  of  propellant  mass  margin.  The 
margined  amount  of  propellant  was  sized  to  completely  fill  up  two  4  cm  high 
modules,  the  resulting  mission  duration  was  119  days. 


Propellant  Trends 


2  cm  High  Module,  1.71  kg  N20 


6  cm  High  Module,  6.27  kg  N20 


N20,  lsp=  120  s,  Three  Module  Heights  in  cm 


•  Thrusters,  Valves,  &  Electronics  U 

Mounted  to  Bottom  Bulkhead 

•  Module  Height  Free  to  Expand  1 

for  Added  Volume 

•  AV  Computed  for  2  Modules 

•  AV  Roughly  Correlates  with  jfl 
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This  slide  shows  the  concept  of  modularity  extended  to  the  Maneuvering  Propulsion 
module  itself,  in  that  it  can  be  produced  in  three  different  yet  very  similar  sizes 
based  on  mission  requirements.  To  increase  the  size  the  side-wall  height  and 
internal  support  post  height  are  merely  duplicated  one  or  two  extra  times.  In  each 
case  the  immersed  board  with  integrated  valves,  feed  system  and  electronics  is 
mounted  to  the  bottom  bulkhead. 

For  illustrative  purposes  the  graph  shows  the  available  AV  from  two  modules  as  a 
function  of  total  SCOUT  dry  mass  for  each  of  the  three  different  propulsion  module 
sizes.  The  green  circle  shows  where  on  the  graph  the  baseline  SCOUT  Escort 
configuration  lies  and  what  the  effects  on  performance  would  be  for  changes  in  dry 
mass  and  module  size.  The  AV  shown  on  the  vertical  axis  is  roughly  directly 
correlated  with  mission  duration. 


The  graph  above  shows  the  projection  of  the  Escort’s  orbit  relative  to  the  primary  in 
the  primary’s  in-track  and  radial  directions.  The  orientation  of  this  plane  as  it  would 
be  seen  by  an  observer  on  the  ground  looking  at  a  GEO  satellite  overhead  is  shown  in 
the  diagram  on  the  top-right. 

To  minimize  propellant  usage,  Escort  spends  most  of  its  time  passively  orbiting  its 
primary  satellite.  Alternatively,  Escort  can  also  lead  or  trail  the  primary  satellite 
separated  by  a  fixed  true  anomaly.  The  primary  satellite  is  assumed  to  be  in  a 
circular  GEO  orbit  and  Escort  is  slightly  offset  from  that  orbit. 

A  slight  true  anomaly  offset  will  cause  Escort  to  lead  or  trail  the  primary.  A  slight 
apogee  and  perigee  (or  semi-major  axis  and  eccentricity)  offset  will  cause  Escort  to 
orbit  relative  to  the  primary  in  the  radial  and  in-track  directions. 

The  dynamics  of  orbits  relative  to  a  primary  satellite  are  somewhat  counter-intuitive. 
The  radial  and  in-track  motions  are  inexorably  coupled:  the  in-track  radius  of  the 
relative  orbit  will  always  be  twice  the  radial  radius.  The  cross-track  radius  is 
uncoupled  and  can  be  independently  controlled.  Another  counter-intuitive  point  is 
that  the  smaller  the  radius  of  the  Escort’s  orbit  relative  to  the  primary  is,  the  slower 
the  Escort  moves  relative  to  the  primary.  This  has  advantages  from  the  standpoints 
that  it  is  safer  to  move  slower  when  the  Escort  is  closer  to  the  primary,  and  also  that 
fatures  on  the  primary  will  still  be  moving  passing  through  the  Escort  FOV  slowly 
enough  to  be  inspected. 


c'Vs  Aero  Astro 


A  slight  inclination  offset  will  cause  Escort  to  orbit  relative  to  the  primary  in  the 
cross-track  direction. 

Based  on  preliminary  discussion  with  stakeholders,  the  minimum  distance  between 
the  center  of  Escort  and  the  center  of  the  primary  is  expected  to  be  on  the  order  of 
100  meters.  The  maximum  distance  is  expected  to  be  on  the  order  of  1,500  meters. 
The  typical  maximum  length  dimension  of  a  large  primary  is  on  the  order  of  50 
meters.  The  typical  smallest  feature  size  of  interest  is  on  the  order  of  1  centimeter. 
The  simple  imager  payload  baseline  is  capable  of  meeting  both  the  50  meter  and  1 
centimeter  requirements  within  the  specified  operational  distances  to  the  target. 


Orbits  Relative  to  GEO:  In-Track  vs  Cross  Track 
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This  chart  simply  shows  a  merged  projection  of  selected  data  that  was  also  shown 
on  the  previous  two  charts. 

It  should  be  noted  that  these  charts  have  only  shown  Keplerian  orbits.  Non- 
Keplerian  trajectories  can  also  be  achieved  at  the  expense  of  using  more  propellant 
and  therefore  having  a  shorter  active  mission  duration.  A  desirable  non-keplerian 
trajectory  might  be  to  station-keep  at  a  fixed  point  relative  to  the  primary  with  some 
separation  in  the  radial  or  cross-track  dimension,  the  further  away  this  point  is 
radially  the  more  propellant  it  will  take.  Another  good  idea  might  be  to  fly  a 
sweeping  “raster  scan”  pattern  through  the  main  beam  of  the  primary  satellite’s 
communications  payload,  this  would  be  useful  for  rapid  antenna  gain  geometry 
mapping  using  the  RF  Probe. 


AD&C  Primary  Pointing  Mode 


Error  Commanded  Thruster  Pair  Actual  Actual  Actual 

Rotation  Rates  Torques  Duty  Cycles  Torques  Rotation  Rates  Quaternions 


Error  Sensed  Sensed 
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We  begin  the  discussion  of  the  ADCS  with  a  functional  block  diagram.  The  control 
loop  type  for  the  Primary  Pointing  and  Primary  Acquisition  modes  is  a  classical 
double  nested  single  input  vector  single  output  vector  control  system.  The  main 
difference  between  the  two  modes  is  the  outer  loop  sensor,  which  is  the  imager  in 
the  Pointing  mode  and  the  star  tracker  in  the  Acquisition  mode.  The  inner  loop  uses 
information  from  the  rate  sensors  and  runs  at  a  higher  frequency  than  the  outer  loop. 
In  a  high  level  sense  this  control  loop  is  similar  to  what  is  used  in  AeroAstro’s 
STPSat-1  satellite  being  built  for  the  US  Air  Force  Space  Test  Program.  The  fast 
loop  controller  would  be  a  traditional  bang-bang  nonlinear  controller  using  a 
Schmitt  trigger  in  a  feedback  loop  with  a  lag.  In  Maneuver  mode  during  larger 
translational  propulsive  maneuvers  the  optimal  jet  selection  logic  can  be  based  on 
that  which  was  developed  for  AeroAstro’s  SPORT  Small  Payload  Orbit  Transfer 
Vehicle.  Other  control  modes  would  have  different  architectures,  for  example,  the 
Detumble  and  Maneuver  modes  might  only  have  a  single  loop  using  the  rate 
sensors. 

The  color  coding  on  the  blocks  indicates  which  module  the  functional  element 
resides  in.  The  SCOUT  avionics  architecture  makes  integrating  different  modules 
very  easy.  At  the  time  of  integration  the  MUGSE  analyzes  the  module  stack  up  and 
adjusts  settings  such  as  gains  and  reference  vectors  in  the  ADCS  software  based  on 
the  computed  moments  of  inertia,  fuel  tank  locations  and  loading,  and  also  thruster 
and  sensor  topologies. 


Attitude  Sensor  Selection 


>  Robust  Design  Meets 
Requirements  for  Multiple  Frames 

•  Multiple  ST  FOV  prevents  Sun, 
Moon,  Earth  induced  loss  of  lock 

•  Insensitive  to  orbit  selection 

•  Allows  for  autonomous  initial 
acquisition  and  Lost  in  Space  mode 

•  Sun  and  rate  sensors  allow  easy 
autonomous  detumble  and  power- 
safe  modes 

>  Potential  Component  Vendors 

•  AeroAstro  Medium  Sun  Sensors  / 

•  AeroAstro  Miniature  Star  Trackers  -* 

•  Systron  Donner  BEI  Gyrochips 
(Rate  Sensors) 


nsor .  $s  rame .  uantity 


Rate'  '  i/B^dy  : 

Star,  3/inertial :  .4  FOV,  2  CPU 


Attitude  Determination 
Module 
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The  Escort  mission  demands  a  variety  of  attitude  determination  sensors: 

Star  tracker,  for  when  the  primary  satellite  is  temporarily  out  of  view 
Sun  sensor,  for  when  the  Escort  is  in  hibernation  or  battery  charging  mode 
Imager,  for  attitude  determination  relative  to  the  primary  satellite 
Body  rate  sensors,  for  when  the  Escort  needs  to  detumble  and  to  propgate  the 
attitude  between  environmental  sensor  updates 

Without  advanced  technologies  such  as  AeroAstro’s  coarse  star  tracker, 
AeroAstro’s  medium  sun  sensors,  or  MEMS  rate  sensors  produced  by  a  variety  of 
other  manufacturers,  a  sufficiently  compact  yet  capable  attitude  determination  suite 
would  not  be  possible.  It  is  also  fortunate  that  the  imager  which  can  be  used  for 
attitude  determination  serves  a  dual  purpose  as  a  payoad  sensor. 

As  many  as  four  coarse  star  tracker  apertures  and  two  processors  should  be  used  to 
prevent  sun,  Earth,  moon  or  primary-induced  loss  of  lock.  The  attitude  sensor 
selection  is  insensitive  to  orbit  selection,  making  it  usefull  for  both  LEO  and  GEO, 
and  it  is  also  capable  of  recovering  from  a  lost-in-space  mode. 


AeroAstro  Miniature  Star  Tracker 


>  MDA  Phase  1  STTR  w /  MIT  Space  Systems  Lab 

•  AH  Information  Still  Very  Preliminary 

•  Phase  2  Proposal  In  Process 

>  Requirement  Goals 

•  Mass  &  Volume:  300  g,  5.1  X  7.6  X  7.6  cm 

•  Power  &  Voltage:  <  1  W,  4.5  -  5.5  VDO 

•  S/M/E  Exclusion:  50°  Full  Angle  Cone 

•  Accuracy  (3-axes,  3a):  <  300  arc-sec  (0.083°) 

•  Max  Roll  Rate:  0.3  deg/sec 

•  Autonomy:  Acq.,  Track,  Process  Att. 

•  Update  Rate:  1  Hz  (increase  w /  power) 

•  Cost:  <~$100k 

>  Technologies 

•  Pin-Hole  Aperture,  No  Glass,  No  Baffle,  Greatly] 
Reduced  Calibration,  25°  Full  Angle  Cone  FOV  j 

•  CMOS  Imager,  No  CCD,  Greatly  Reduced**' 
Electronics  Mass,  Volume  and  Power 

•  <=  4  Pairs  of  <=  4th  Mag.  Stars  ,  * 
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Low  cost  space  vehicles  require  an  affordable,  low  system-impact  sensor  for 
attitude  determination.  This  is  especially  true  when  a  high  degree  of  navigation  is 
required  for  high  delta- v  maneuvers  in  applications  such  as  on-orbit  interceptors. 
General  industry  research  is  focused  on  increasing  accuracy  to  the  exclusion  of  all 
else.  It  focuses  on  rapid  pattern  recognition,  widening  fields  of  view  to  process 
many  stars  and  star  patterns  simultaneously,  and  expanding  internal  star  catalogs  to 
well  over  20,000  stars  ranging  from  magnitude  0  to  magnitude  9.  These  advances 
all  result  in  more  massive  and  complex  systems.  This  is  contrary  to  the  clear 
requirement  for  decreased  complexity,  mass,  and  power  consumption  to  fit  the 
needs  of  small,  highly  maneuverable,  low-cost  vehicles.  AeroAstro  and  MIT  are 
jointly  developing  a  highly  innovative  electronic  device  to  solve  this  challenge:  a 
low-impact  star  tracker,  balancing  accuracy  with  power  consumption,  mass,  and 
cost.  No  solution  currently  exists  in  this  area  of  the  trade  space.  The  design  uses  a 
pinhole  in  place  of  traditional  optics,  takes  advantage  of  the  processing  capabilities 
embedded  in  newer  CMOS  imagers  to  reduce  power  consumption  and  limit  the 
amount  of  glue  logic  required,  and  exploits  highly  compact  pattern  recognition 
algorithms  to  find  star  pairs  using  a  minimal  star  catalog.  The  solution  offers 
accuracy  better  than  100  arc-seconds,  meeting  the  unique  requirements  of  small 
maneuverable  space  vehicles  at  a  fraction  of  the  cost,  mass,  and  power  consumption 
of  larger,  higher  impact  star  trackers. 


AeroAstro  Medium  Sun  Sensor 


> 

> 

> 

> 

> 

> 

> 

> 

> 


Heritage:  ALEXIS,  HETE,  CHIPSat,  soon  MOST 
Detector:  Masked  Quadrant  Photo-Diode 
Output:  2  Axes  in  Sun  Frame 
Calibration  Table  or  Function  Stored  in  Spacecraft 
Avionics 

FOV:  134°  Full  Angle  Conical 

Accuracy:  ~1  °,  3cr  (Higher  Available) 

Mass:  36  g  (w/  Harness) 

Power:  None 

Cost:  <  $50  k  for  two 
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AeroAstro’s  Medium  Sun  Sensor  is  a  low-cost,  medium  resolution  sun  sensor  that 
was  originally  designed  and  built  by  AeroAstro  for  the  Los  Alamos  National 
Laboratory’s  ALEXIS  satellite  and  has  since  been  used  on  several  others  too.  The 
sun  sensor  is  comprised  of  a  small  housing  containing  a  set  of  four  photodiodes. 

The  sensor  provides  four  signal  outputs  and  one  ground  wire.  The  satellite’s 
computer  must  store  a  small  table  of  calibration  data  and  a  small  interpolation 
subroutine  to  compute  the  sun  angle  based  on  four  signal  outputs. 

The  housing  used  for  the  Medium  Sun  Sensor  also  serves  as  the  aperture.  The 
accurately  machined,  integrated  aperture  reduces  mechanical  complexity,  while 
serving  to  precisely  mask  solar  light  to  provide  the  desired  field  of  view  and 
illumination  properties.  The  robust  aperture  also  effectively  protects  the 
photodiodes  during  integration  and  testing.  A  specially  designed  mask  limits  the 
entry  of  stray  light  into  the  sensor. 

AeroAstro  has  developed  custom  light  geometry  processing  and  visualization 
software  for  determining  optimum  placement  of  sun  sensors  on  spacecraft.  This  is 
especially  useful  for  AeroAstro’s  Coarse  Sun  Sensor  that  produces  attitude  output 
based  only  on  sun  intensity  measured  at  different  locations  on  the  body.  More 
sophisticated  versions  of  this  software  are  used  for  solar  panel  string  layout  design 
and  power  output  analysis,  as  well  as  for  computing  solar  pressure  and  aerodynamic 
disturbance  torques. 


Systran  Donner  BEI  GyroChip  QRS11 


>  Heritage:  Numerous  Aircraft,  Missile 
and  Space  Systems 

>  Detector:  Solid  State  MEMS 
Piezoelectric  Quartz  Tuning  Fork 

>  Output:  1  Axis  Rate  in  Body  Frame 

>  Threshold/Resolution:  <  0.004°/sec 

•  Not  Used  for  Integration 

>  Noise:  < 

0.01o/sec/VHz 

•  0  to  100  Hz 

>  Saturation:  ±50°/sec 

•  Internal  Anti  Aliasing  Filter 

>  Mass:  £  60  g 

>  Power:  0.8  W 

•  ±5  V 

>  Cost:  <  $3000 
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The  BEI  GyroChip™  Model  QRS1 1  is  a  “MEMS”  technology,  solid-state  “gyro  on 
a  chip.”  This  DC  input/high-level  DC  output  device  is  fully  self  contained, 
extremely  small  and  lightweight.  No  external  support  electronics  are  required. 

Since  the  inertial  sensing  element  is  comprised  of  just  one  micromachined  piece  of 
crystalline  quartz  (no  moving  parts),  it  has  a  virtually  “unlimited”  life.  The  Model 
QRS1 1  is  a  mature  product  in  high  volume  production.  It  is  fully  qualified  and  used 
on  numerous  advanced  aircraft,  missile,  and  space  systems. 

The  BEI  GyroChip™  Model  QRS1 1  utilizes  a  one  piece,  micromachined,  vibrating 
quartz  tuning  fork  sensing  element.  Applying  the  Coriolis  effect,  a  rotational  motion 
about  the  sensor’s  input  axis  produces  a  DC  voltage  output  proportional  to  the  rate 
of  rotation.  Use  of  piezoelectric  quartz  material  simplifies  the  active  element 
resulting  in  exceptional  stability  over  temperature  and  product  life.  (Above  two 
paragraphs  from  product  data  sheet) 

This  gyro  technology  was  initially  conceptualized  by  a  Swiss  watch  company  that 
was  using  it  for  precision  oscillators.  The  watch  company  later  sold  the  rights  to  its 
use  in  gyros  to  Systran  Donner.  After  further  development  Systran  Donner 
determined  that  the  technology  would  require  significant  further  development  to  be 
useful.  They  retained  three  expert  engineers,  one  each  in  the  fields  of  dynamics, 
electrical  engineering,  and  software  to  get  the  gyros  working.  Professor  Dan  DeBra 
of  Stanford  was  the  dynamics  engineer,  he  is  also  a  member  of  AeroAstro’s  board 
of  directors. 


Attitude  Determination  Module 


>  Contains  All  Attitude  Determination 
Components 

3  GyroChips 

4  Miniature  Star  Cameras 
Electronics 

-  2  Star  Tracking  Processors 

-  4  MSS  Calibration  Tables 

-  Filtering 

-  SCOUT  Core  Electronics  Block 
4  Medium  Sun  Sensors 

>  6  cm  Tall  Module 
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This  slide  shows  a  conceptual  packaging  of  the  attitude  determination  module. 

Each  of  the  AeroAstro  Miniature  Star  Trackers  is  shown  in  its  current  nominal 
configuration  which  includes  both  aperture  and  all  processing  electronics,  and 
would  actually  have  the  bore-sight  pointed  out  the  top.  Although  they  would  not  be 
functional  as  shown,  the  slide  shows  that  volumetrically  they  would  all  fit  in.  The 
appropriate  engineers  have  determined  that  it  would  be  possible  to  re-package  each 
individual  star  tracker  to  point  the  bore-sight  out  the  side  and  then  also  still  keep  the 
height  below  the  6  cm  standard  module  height.  This  is  especially  feasible  if  the 
processing  electronics  are  offloaded  to  the  centralized  board  stack. 

This  module  configuration  is  slightly  different  compared  to  what  was  presented  in 
the  SCOUT  Technology  Plan.  The  main  difference  is  that  the  magnetometer  was 
removed.  This  was  done  because  AeroAstro  decided  that  magnetometers  are  a  poor 
choice  for  attitude  determination  when  more  accurate  sensors  are  already  available 
within  the  same  module.  Instead,  the  magnetometer  should  be  included  with  what 
was  previously  the  magnetic  actuation  module  for  use  in  compensating  for  the 
unknown  variability  of  Earth’s  magnetic  field  when  commanding  the  magnetic 
actuators. 


Attitude  Actuator  Selection 


>  Thrusters  also  very  good  choice  because  they  can  supply 
needed  propulsive  maneuvering  capability 


A  variety  of  different  attitude  control  designs  were  evaluated,  as  shown  in  Table  3. 
Bang-bang  thrusters  were  selected,  because  they  provide  the  best  attitude  control 
capabilities  and  also  because  they  could  be  used  for  translational  control  which  is 
required  by  the  Escort  mission.  The  desired  characteristic  for  each  row  of  the  trade 
matrix  is  Low,  except  for  Slew  Capability,  where  the  desired  characteristic  is  High. 
Bang-bang  thrusters  are  the  only  option  that  meets  all  the  desired  characteristics. 
Even  if  one  of  the  other  concepts  was  selected  thrusters  would  still  be  required  for 
translational  maneuvering.  Concepts  using  magnetic  actuation  in  any  way  were 
discarded  because  of  the  low  magnetic  field  strength  in  GEO. 


Attitude  Impulse  Sizing 


>  Major  Assumptions: 

•  Altitude  and  Inclination:  GEO 

•  Solar  Pressure  Moment  Arm:  6.25  cm 

•  Average  Moment  of  Inertia:  4.67  kg  m2 

•  Residual  Magnetic  Dipole:  1  Am2 

•  Average  Thruster  Moment  Arm:  0.191  m 

•  Thrusters  Fired  in  Pairs  for  Each  Axis 

•  Nominal  Control  (3a,  3-Axes):  +/- 1.5° 

-  Limit  Cycle:  256  sec 

-  Time  Between  Firings:  256/2  =  128  sec 

-  Jitter:  <=  0.047  °/sec  (Rigid  Body  Analysis) 

•  Minimum  Impulse  Bit:  0.01  Ns 

-  Valve  Open  Time:  0.1  sec 

-  Valve  Power  Time:  0.2  sec 

-  Thrust:  0.1  N 

•  Two  4  cm  High  Maneuvering  Modules 

-  Achievable  Mission  Lifetime:  119  days 

-  Achievable  Mission  Duty  Cycle:  100% 
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External  Disturbance 

Torque  (Nm) 

Solar  Pressure 

5.9e-7 

Gravity  Gradient 

2.7e-8 

Aerodynamic 

0 

Residual  Magnetic  Dipole 

2.1e-7 

Total 

8.3e-7 

Torque  Impulse  Source 

impulse  (Nms) 

External  Disturbance 

45 

Attitude  Limit  Cycle 

4820 

Total 

4865 

The  attitude  control  momentum  impulse  requirement  is  calculated  by  assuming  that 
Escort  has  to  continuously  fight  the  maximum  possible  environmental  disturbance 
torque  and  also  continuously  perform  a  bang-bang  attitude  limit  cycle.  Over  the 
1 19-day  active  life  of  the  SCOUT  Escort  in  GEO,  the  limit  cycle  impulse  is 
approximately  two  orders  of  magnitude  larger  than  the  disturbance  torque  impulse. 
Estimates  for  solar  pressure  moment  arm  and  residual  magnetic  dipole  were 
conservative.  The  limit  cycle  period  and  amplitude  was  verified  by  computing  it 
two  different  ways.  The  jitter  analysis  assumed  that  the  SCOUT  was  a  rigid  body, 
at  a  later  stage  of  analysis  flexible  body  modes  including  fuel  slosh  and  solar  panel 
vibrations  could  be  included. 


AD&C  Mode  Switching  Diagram 


The  nominal  mode  of  operations  is  Primary  Pointing  with  periodic  excursions  to 
Sun  Recharge  for  simultaneous  recharging  and  payload  data  downlink.  If  the  lock 
on  the  primary  needs  to  be  initially  acquired  or  if  it  is  ever  lost  then  the  Primary 
Acquisition  mode  can  be  used.  In  Primary  Acquisition  mode  the  star  tracker  is  used 
to  guide  a  sweeping  search  pattern  for  the  imager.  A  separate  Maneuver  mode  is 
available  for  larger  propulsive  translational  maneuvers  to  change  the  orbit  of  the 
Escort  relative  to  the  primary.  Unless  the  Escort  is  spinning  on  purpose,  if  it  ever 
enters  a  tumble  then  the  Detumble  mode  is  activated  after  which  it  returns  to  a  non¬ 
spinning  Sun  Safe  mode.  Because  the  Escort  may  not  be  needed  all  the  time  a 
Hibernate  mode  is  also  available  in  which  it  is  placed  into  a  slow  spin  with  the  solar 
panels  pointed  at  the  sun.  While  hibernating  it  can  periodically  wake  up  and 
precess  its  spin  vector  towards  the  sun  if  it  drifted  away. 
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The  following  set  of  slides  are  for  the  power  subsystem  for  the  SCOUT  architecture. 
This  presentation  was  developed  as  part  of  the  final  review  for  the  SCOUT  phase  I 
SBIR  program. 


Power  Requirements 


Sunlight 

Eclipse 

Eclipse 

Modules 

Module 

Sunlight 

Average 

Duty 

Average 

Average 

Used 

Name 

Power 

Duty  Cycle 
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The  spreadsheet  shown  in  here  is  part  of  a  larger  spreadsheet  that  keeps  detailed 
power  information  for  all  of  the  conceived  SCOUT  modules.  This  spreadsheet 
makes  it  easy  to  select  the  desired  modules,  setup  up  operation  profiles  (duty  cycles) 
and  tally  up  their  power  requirements.  The  spreadsheet  also  keeps  track  of  battery 
and  effective  solar  array  area. 


Power  Architecture 


>  Direct  Energy  Transfer 
power  system  architecture 

>  Shunt  Regulator  located 
on  the  Solar  Array  module 

>  Batteries  and  Battery 
Charger  in  Battery  module 

>  Battery  Module  supports 
up  to  four  independent 
batteries 

•  Additional  battery 
modules  can  be  added 
for  greater  battery 
power  storage  capacity 

>  Outstanding  challenges: 

•  Handling  power 
dissipation  from  Shunt 
Regulator 
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The  power  subsystem  has  been  divided  into  two  independent  slices  for  power 
storage  be  it  primary  or  secondary,  and  power  collection. 


Power  Collection  Module  will  house  the  deployable  solar  arrays  and  the  shunt 
regulator  while  the  power  storage  module  will  house  the  batteries  and  battery 
management  electronics 


Solar  Arrays 


>  Currently  investigating  two 
competing  solar  cell  technologies 

•  Triple  Junction  GaAs 

-  High  Efficiency  ( >20% ) 

-  High  Cost  ( $100’s  K ) 

-  Moderate  Power  Density 
( less  than  50W  per  kg ) 

•  Thin  Film  CIS 

(Copper  Indium  Diselinide) 

-  High  Energy  Density 

(  greater  than  100W  per  kg  ) 

-  Easy  to  package 

-  Relatively  new  technology 

-  Low  Efficiency 

( approx.  10%  at  cell  level) 
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Two  different  solar  array  technologies  are  being  studied  for  SCOUT;  rigid  triple 
junction  GaAS,  and  Thin  film  CIS.  Selection  of  the  specific  technology  will  be 
conducted  during  phase  II  of  the  study. 


The  spreadsheet  shown  on  this  slide  depicts  the  effective  solar  array  area  required 
by  the  ESCORT  version  of  SCOUT 


Thin  Film  Deployment  Options 


SPORT  Concept  inflatable  Array  Roll-Out  Array 


to  1  kW  ( >  100  W/kg  ) 
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AeroAstro  has  studied  different  mechanism  for  deploying  membranes  and  thin  film 
solar  arrays  during  the  Phase  I  and  Phase  II  Aerobrake  SBIRs.  Some  of  the 
considered  concepts  are  depicted  in  this  slice. 


Note  Not  all  of  the  concepts  are  AeroAstro  proprietary. 


Lithium-Ion  Batteries 


1  String:  138  W-Hr 

2  Strings:  276  W-Hr 

3  Strings:  414  W-Hr 


>  Battery  Slice  houses  up  to  4 
independent  battery  strings 

>  String  Specifications: 

•  4.8  A-Hr 

■  33.6  V  OVC _ 
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Concepts  for  two  different  power  storage  slices  have  been  designed;  a  fat  Lithium 
Ion  battery  box  (depicted  in  this  slide)  and  a  thin  Lithium-Ion  battery  box  (next 
slide). 


The  fat  Lithium-Ion  battery  slice  can  house  up  to  four  independent  battery  strings 
along  with  their  management  electronics.  Depending  on  power  needs  of  the 
spacecraft  one,  two,  three,  or  all  four  battery  boxes  can  be  populated.  Mass 
equivalents  will  be  available  to  drop  in  place  of  unused  battery  strings. 


For  added  power  storage  capabilities,  two  or  more  battery  slices  can  be  stacked  up 
in  the  same  SCOUT  spacecraft.  It  will  also  be  possible  to  add  primary  batteries  If 
necessary. 


Lithium-Ion  Batteries  (Alternative  configuration) 


>  Battery  Slice  houses  a  single 
battery  string 

>  String  Specifications: 

•  4.8  A-Hr 

•  33.6  VOVC 

>  Flat  configuration  will  allow  us  to 
minimize  overall  spacecraft 
volume  and  height  when  only  one 
or  two  battery  strings  are 
required 


>  At  present,  flat  battery  configuration 
violates  the  2cm  slice  height 

>  Plan  to  evaluate  alternative  cell 
manufacturers  and  dimensions  to 
stay  within  slice  envelope  volume 
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An  alternative  to  the  fat  battery  slice  that  takes  up  unnecessary  volume  in  the 
SCOUT  configuration  in  which  only  a  single  string  is  necessary,  a  thin  battery  slice 
has  been  designed.  This  battery  slice  will  house  a  single  battery  string  as  depicted 
in  this  slide.  Multiple  thin  battery  slices  can  be  stacked  together  or  in  combination 
with  the  fat  battery  box. 


At  present  the  thin  battery  slice  violates  the  2cm  slice  clearance.  One  of  the 
solutions  are  to  investigate  different  cell  manufacturers  and/or  capacities. 
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The  following  set  of  slides  is  for  flight  software  for  the  SCOUT  vehicle.  This 
presentation  was  developed  as  part  of  the  final  review  for  the  SCOUT  phase  I  SBIR 
program. 


The  Flight  Software  will  be  divided  into  a  number  of  layers  and  modules  (within  each  layer)  making 
it  portable,  flexible,  modular. 

Portable;  by  abstracting  the  higher  layers  of  the  software  (Spacecraft  managers,  C&DH,  etc)  we  can 
divorce  the  implementation  of  this  layers  from  the  hardware. 

Flexible  behavior  of  the  spacecraft  revolves  around  a  set  of  infrastructures  that  FaU&Uplpader 
telemetry  gathering,  communications,  and  health  and  maintenance.  A  simple  framework  will  enable 
the  operator  to  set  the  behavioral  rules,  by  which  the  spacecraft  operates. 

Modular;  each  hardware  slice  will  have  a  corresponding  software  module,  which 
software  utilizes  for  commanding  the  slice.  Slices  are  hierarchically  categorized  by  tne  Junction  they 
perform  and  the  information  they  provide  and  or  require.  By  organizing  modulJVISiRtfiUflnC© 
described  above  we  can  define  high  level  software  ICDs  for  the  modules  and  identify  commands  and 
data  formats  that  each  similar  module  will  recognize. 


wbeahagigtion, 
eavary  widely; 


For  instance,  SCOUT  has  defined  three  different  GN&C  actuation  modules  (micro-wh 
magnetic  actuation,  and  propulsion).  The  details  of  how  those  modules  are  controlled vary^ 
those  details  are  found  within  the  slice  software  module.  However,  to  the  SCOUT  application  flight 
software  all  three  GN&C  actuation  modules  perform  similar  functions,  to  maneuver  the  spacecraft. 
Defining  a  SCOUT  GN&C  actuation  ICD  that  specifies  the  data  types,  functions,  and  parameters  that 
these  functions  require  would  make  swapping  the  modules  seamless  to  the  field  integrator. 

Power 

Management 


Modularity 
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This  graph  shows  a  more  traditional  view  of  the  flight  software  architecture.  It  also 
depicts  the  interactions  and  the  data  interfaces  between  the  different  layers  of  the 
flight  software. 


GN&C 

Framew 


X-band  l 
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Commanding 


>  Real-time  commanding 

•  Commands  are  forwarded  to  the  appropriate  process  or  module  for 
immediate  execution 

>  Event  based  commanding 

•  Executed  at  a  later  time  based  on  detection  of  an  "event" 

-  The  arrival  of  a  specified  time  is  an  "event"; 

time-tagged  commanding  is  a  subset  of  event-based  commanding 

•  Implemented  utilizing  an  event  handler  library 

-  Includes  table  manipulation  commands 

-  Table  telemetry  includes: 

■  Entry  number 

■  Major/Minor  type 

■  Execution  time/event 

•  Stored  command  table  maintained  by  command  handler 

-  Permanent  commands  loaded  at  system  startup 

-  Temporary  commands  loaded  by  ground 

-  Both  are  modifiable 
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Commanding  of  the  spacecraft  is  done  either  by  uploading  commands  to  the  stored 
command  table  or  by  having  permannent  commands  loaded  during  the  power-up 
sequence.  All  of  the  command  on  the  command  table  are  accessible  and  modifiable 
by  the  ground  operators. 


Commanding  is  event  based;  that  is  commands  placed  on  the  stored  command 
table  will  be  triggered  by  an  event  such  as  time,  upload  carrier  detected,  other 
commands,  etcetera. 


Telemetry 


>Collects  telemetry  from  vehicle  subsystems  and  modules 

> Services  telemetry  queue 

•  Messages  routed  to  proper  stream 

-  Real  time  telemetry  sent  to  ground 

-  Stored  telemetry  sent  to  circular  buffer 

>Table-based  telemetry  handler 

•  Telemetry  message 

•  Real  time  rate 

•  Stored  rate  (a  multiple  of  real  time  rate) 

•  Enable/Disable 
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Telemetry  gathering  is  table  based  as  well,  the  C&DH  system  will  post  the  flight 
software  telemetry,  spacecraft  status,  and  slice  status. 


Telemetry  (Continued) 


>  Real  time  telemetry 

•  Enabled  by  command  from  ground 

-  Continuous  telemetry  stream 

-  No  additional  commands  required 

-  Sent  to  “Low  Priority”  Queue,  not  to  interrupt  payload  data 

-  Disabled  by  disconnect  from  ground  or  command 

>  Stored  telemetry 

•  Collected  continuously 

•  Stored  in  circular  buffer 

•  Configurable  to  either  overwrite  buffer  or  stop  collecting  telemetry 

>  Storage  Rates 

•  Three  Rates  (H,M,L)  for  each  (Real  Time/Stored) 

-  High  Rate:  once  every  3  seconds  (approximately) 

-  Medium  Rate:  once  every  30  seconds  (approximately) 

-  Low  Rate:  once  every  5  minutes  (approximately) 

•  Adjusted  as  necessary  to  meet  storage  and  mission  requirements 
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As  mentioned  earlier,  the  ground  operator  as  the  option  to  get  real  time  telemetry 
updates;  he/she  can  selected  to  see  all  or  part  of  the  telemetry  points. 


Telemetry  is  stored  in  a  circular  buffer;  the  operator  will  have  the  ability  to  set  the 
spacecraft  to  either  overwrite  or  cease  storing  telemetry  once  the  buffer  is  full.  The 
telemetry  table  will  continue  to  be  updated  at  the  regular  bases. 


The  operator  can  choose  what  telemetry  points  it  wants  stored  and  at  which 
frequency  by  setting  the  storage  rates. 


Software  Development  Process 


> Small  design  team  assigned  to  each  module 

-  Follows  the  AeroAstro  design  buddy  approach 

-  Design  and  implementation  by  primary  buddy 

-  Module  test  and  release  by  secondary  buddy 

>Code  management 

•  Version  control 

-  Utilizing  CVS  software 

-  Baseline  tracking 

-  Code  release  management 

•  Bug  Tracking 

-  Utilizing  Mantis  software 

(an  open-source  bug  tracking  and  reporting  software  package) 

-  Assign,  categorize,  track,  and  provide  status  on  anomalies 
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Each  SCUOT  module  will  have  a  small  team  (preferably  2)  of  engineers  responsible 
for  the  design,  implementation,  and  testing  of  the  module. 


AeroAstro  employs  a  number  of  tools  for  version  control  of  the  software  and  well  as 
tracking  anomalies;  those  tools  will  be  used  during  the  development  of  SCOUT 
software  as  well. 


Software  Integration  &  Test 


>  Ground  l&T  Support 

•  The  Master  Universal  Ground 
Support  Equipment  (MUGSE) 
will  be  used  for  all  SCOUT  l&T 

•  MUGSE  will  be  used  to  upload 
and  troubleshoot  the  latest 
version  of  software  and  drivers 

>  On-Orbit  software  upload 

•  Operators  can  upload  software 
patches  or  entire  image  to  S/C 

•  Operator  has  the  ability  to  test 
uploaded  software  before 
committing  to  flash 

•  In  case  of  failure  during  test, 
the  S/C  will  reset  and  load  last 
known  good  software  image 

•  S/C  has  capability  to  have 
multiple  images  in  flash 
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A  MUGSE  will  be  used  for  interacting,  servicing,  and  diagnosing  the  SCOUT 
spacecraft  and/or  any  combination  of  slices.  The  MUGSE  will  connect  to  the 
Spacecraft  via  an  Ethernet  network  connection. 


Software  images  or  a  patch  to  a  software  image  can  be  uploaded  at  any  time  by  an 
operator.  The  Spacecraft  can  be  instructed  to  execute  the  uploaded  software  and 
commit  (write  it  to  FLASH)  to  it  once  the  newly  uploaded  software  has  been  tested. 
If  an  anomaly  where  to  occur  during  the  upload  or  test  periods,  the  spacecraft  will 
reset  and  load  the  last  good  know  software  image. 


Software  Test  Approach 


>  Integration  support 

•  MUGSE  will  be  used  for  all  SCOUT 
Integration  &  Test  (l&T)  activities 

•  MUGSE  allows  test  of  individual 
modules  or  fully  integrated  spacecraft 

•  MUGSE  provides  power,  CMD,  and 
low-  and  high-speed  TLM  interfaces 

•  MUGSE  will  be  used  to  upload  the 
latest  versions  of  software  and  drivers 

>Test  Flow 

•  Functional  unit  or  module  test 

•  Software  integration  and  validation 

•  SCOUT  module  test 

•  Integration  and  Test 

•  Formal  system  level  l&T 

•  Formal  acceptance  test 
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>  Test  Categories 

•  Functionality 

•  Performance 

•  Resource  Utilization 

•  Adherence  to  interface  specifications 

•  Timing  constraints 

•  Induce  error  conditions  such  as 
subsystem  or  module  power  cycle 
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Testing  will  be  done,  witch  one  exception,  in  a  very  traditional  way,  test  functions, 
subsystem,  spacecraft.  Testing  for  functionality,  performance,  timing  issues,  etc. 


One  exception  will  be  that  each  slice  will  be  individually  tested  and  qualified  for 
SCOUT  so  that  only  a  quick  functional  test  will  be  necessary  when  it  is  integrated  in 
the  field  with  the  rest  of  the  SCOUT  vehicle. 


Software  Diagnostics  and  Field  Testing 


>  Operators  and  integrators  can  easily  perform  testing  and 
diagnostics  by  using  built-in  diagnostic  routines 

>  Each  module  will  be  loaded  with  self-diagnostic  routines 

>  Well-defined  diagnostic  codes  will  assist  operators  and 
integrators  to  efficiently  identify  faulty  components 

>  Built-in  test  and  diagnostics  can  be  executed  from  either 
the  MUGSE  workstation  or  while  in  orbit 

•  In  orbit,  diagnostic  codes  will  be  transmitted  to  the  ground 

>  MUGSE  will  incorporate  a  Graphical  User  Interface  to 
simplify  selection  of  tests  and  interpretation  of  returned 
diagnostic  codes  and  error  messages 
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One  of  the  tasks  that  each  CEB  must  perform  is  to  perform  a  series  of  Built-In-Tests 
(BIT)  as  defined  by  the  specific  design  of  the  slice.  Each  BIT  has  pass/fail  criteria 
for  every  component  been  tested.  These  tests  return  standard  diagnostics  codes  that 
would  allow  the  field  integrator  to  quickly  and  efficiently  identify,  isolate,  and 
replace  faulty  components.  Each  module  is  capable  of  performing  BITs  as  a 
standalone,  by  connecting  the  module  directly  to  a  MUGSE,  or  in  a  SCOUT  stack 
with  or  with  out  the  assistance  of  a  MUGSE.  A  Graphical  User  Interface  on  the 
MUGSE  simplifies  test  selection  and  interpretation  of  returned  diagnostic  codes  and 
error  messages.  Built-In-Test  can  also  be  performed  while  in  orbit.  The  return 
codes  are  transmitted  to  the  ground  as  part  of  the  RF  stream. 
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Command  and  Data  Handling 
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The  following  set  of  slides  is  for  the  Command  and  Data  Handling  subsystem  of  the 
SCOUT  vehicle.  This  presentation  was  developed  as  part  of  the  final  review  for  the 
SCOUT  phase  I  SBIR  program. 


Core  Electronics  Block 


>  The  Core  Electronics  Block 
(CEB)  will  be  required  for 
every  module  in  SCOUT 

>  The  CEB  will  interface  the 
SCOUT  bus  to  instruments, 
subsystems,  and  sensors 

>  The  CEB  will  have  the 
following  functionality: 

•  Low-speed  data  interface 

•  High-speed  data  interface 

•  Power  distribution, 
switching,  and  regulation 

•  A/D  for  TLM,  e.g.,  thermal 

•  Discrete  (logic)  I/O 

•  RS-422  full  duplex  data 

•  Buffer 


■r"  Y* 
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The  Core  Electronics  Block  (CEB)  is  a  small  electronics  board  that  will  reside  in 
each  SCOUT  slice ;  it  will  provide  the  glue  required  to  interface  to  sensors, 
actuators,  and  components  in  the  individual  slices.  The  CEB  will  offer  a  great  deal 
of  functionality  to  each  SCOUT  slice;  specifically  it  will  offer  analog  data 
collection,  discrete  I/O,  serial  interfaces,  secondary  power  regulation  and 
monitoring.  In  addition  the  CEB  will  offer  other  services  to  support  the  SCOUT 
bus  such  as  performing  built-in  tests  (BIT).  At  the  heart  of  the  CEB  will  be  a 
radiation  tolerant  FPGA  for  telemetry  gathering,  control,  and  diagnostics. 


Backbone  Data  Bus  Selection 


The  data  bus  architecture  for  SCOUT  vehicle  has  been  divided  into  two  groups,  one 
that  is  suitable  for  low  data  rate  applications  such  as  commanding  and  telemetry  and 
the  second  that  are  suited  for  high  speed  applications  such  as  imaging.  A  trade  was 
performed  for  both  groups  with  the  cut-off  point  at  1  Mb/sec,  i.e.  any  data  bus 
architecture  that  supports  data  transfers  higher  than  IMb/sec  will  be  considered  high 
speed.  For  the  purpose  of  this  trade  the  following  characteristics  were  evaluated: 

Backplane/Cable:  do  all  participants  on  the  bus  need  to  be  in  the  same  box 
(VME),  or  can  they  be  distributed  around  the  spacecraft  (USB) 

Central/Distributed:  Is  there  one  central  governing  device  which  controls 
who  can  transmit  on  the  bus  at  any  one  given  time,  or  all  the  devices  on  the 
bus  participate  in  arbitration  to  decide  who  can  transmit  or  have  priority 

Number  of  Wires:  The  number  wires  that  are  required  for  the  bus 
Max  Length:  The  maximum  physical  length  of  the  bus 
Data  Rate:  The  maximum  data  rate  of  the 

Payload  Fraction:  What  is  the  maximum  number  of  bits  that  transmitted, 
versus  header  or  other  information 


Backbone  Harness  Connector 


j  j 

Data  I 

Power 

i  Ground 

\?c 

2  1 

0 

0  1 

PC  (redundant)  ! 

2  I 

0 

0 

1802.3 

4  j 

0 

o  | 

iPower 

0  1 

3 

4  | 

j  Power  (redundan 

o  I 

3 

I  4  ! 

jSep  Switches 

4  | 

0 

0 

Isolation 

. 4 . j 

0 

0 

(Sync . 

. 2 . r 

. 0 . 

0  : 

Spares 

5  ! 

0 

[  o 

Total  lines 

23 . j 

6 

8  1  ] 

Connector  Size  >f 

_37j 

>  Harness  Specifications 

•  37-pin  MDM  inter-module  connectors 

•  26-AWG  Teflon  harness 

•  Power  handling  capabilities;  1 .4A  per  line. 

•  Total  power  handling  capability  6X1 .4A  X  28V  =  235W 

•  Isolation  pins  between  power  and  signal  lines 
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MDM  connectors  will  be  used  to  connect  SCOUT  slices  to  the  electrical  backbone 
of  the  vehicle.  A  37  pin  connector  has  been  chosen  to  provide  the  conduit  for 
power,  data,  and  synch  signals.  This  configuration  will  enable  to  SCOUT  system  to 
handle  anywhere  from  235 W  up  to  313W  (is  using  spare  lines  to  route  power).  A 
redundant  set  of  I2C  lines  have  been  added  for  robustness.  Each  slice  will  be  able 
to  access  the  electrical  backbone  by  either  connecting  trough  EMI-filters,  a 
connector,  or  a  cutout.  Having  isolation  pins  and  proper  shielding  will  alleviate 
EMI  concerns. 


The  Cable  Derating  Criteria  follows  the  suggestions  of  NASA’s  GSFC  Preferred 
Parts  List 


C&DH  Module  (Version  III) 
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Depicted  on  this  picture  is  a  Version  III  S&DH  slice.  Included  in  this  particular 
version  is  a  Core  Electronics  Board,  a  Flight  Computer,  and  a  Mass  memory  board. 


C&DH  Module  Versions 


^Version  I 

•  Power  bus 
monitoring 

•  2  MB  RAM  for  TLM 
buffering 

•  Power-Up  and  Reset 
functions 

•  Power  line  fault 
detection 

•  Micro-instruction 
capability  for  low 
level  control  of 
spacecraft 

•  Based  on  radiation- 
tolerant  FPGAs  using 
embedded  triple¬ 
voting  logic 

•  Watch  dog  timers 

•  Processing  of  CMD 
and  TLM  comm 


>  Version  II 

•  Version  I  plus: 

•  55  MIPS 
microprocessor 

•  64MB  EDAC- 
protected  DRAM 

•  Low  speed  data 
interface  (l2C) 

•  High  speed  data 
interface  (IEEE  802.3) 

•  RS-232  interfaces  for 
software  debug  and 
development 

•  pCIOS  Operating 
System 

•  Watch-dog  timers  for 
ha  rd  wa  re/software 
state  of  health 


>Version  III 

•  Version  II  plus: 

•  Up  to  1GB  EDAC- 
protected  SDRAM 
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Figure  1  SCOUT  Avionics  Block  Diagram 

In  order  to  meet  the  avionics  requirements  of  the  different  missions  the  SCOUT 
modular  architecture  could  serve;  AeroAstro  adapted  its  avionics  architecture  to 
provide  additional  modularity,  scalability,  and  adaptability  while  retaining  a  simple 
design.  There  are  three  versions  of  the  SCOUT  avionics,  version  I,  II,  and  III.  Each 
version  increases  the  overall  capabilities  of  the  previous  version  and  of  the 
spacecraft  bus.  By  having  this  modular  avionics  architecture,  SCOUT  can  be  used 
for  a  variety  of  missions  ranging  from  a  simple  experiment  test-bed  to  complex 
applications  such  as  high  resolution  imaging.  The  capabilities  of  each  version  are 
described  in  the  table  below. 


C&DH  Module  -  Version  I 


>  Version  I  is  designed  for  simple 
missions  without  active  AD&C 

>  Ideal  for  applications  such  as: 

•  Microgravity  experiments 

•  Flight  Tech  Demo  missions 
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Version  I  of  the  C&DH  module  is  the  simples  avionics  module.  It  is  designed  to 
support  the  simplest  of  spacecraft  needs  with  out  an  active  Guidance  and  Navigation 
system.  A  Radiation  hardened  FPGA  is  at  the  hear  of  this  module.  This  particular 
version  of  the  avionics  will  be  capable  of  collecting  telemetry,  interpreting  and 
storing  ground  commands,  monitoring  and  reporting  state  of  health,  and  handle 
some  small  amount  of  payload  telemetry  (about  4  MB).  Additionally,  the  Core 
Electronics  will  interface  with  the  Launch  Vehicle  separation  sensors  to  determine 
when  the  Spacecraft  has  been  released  and  initiated  the  power-up  sequence. 


The  Power  Command  and  Telemetry  Board  is  an  integrated,  single-board  solution 
that  provides  the  majority  of  the  capabilities  required  for  a  simple  spacecraft.  A 
first  version  of  this  board  was  originally  developed  by  AeroAstro  for  the  NASA 
SPASE  (Small  Payload  Access  to  Space  Experiment)  nanosatellite.  The  PC&T  is 
built  around  a  radiation-tolerant  Actel  FPGA  that  contains  firmware  to  issue  timed 
commands,  support  communications,  and  command  slices  to  switch  power  lines.  It 
includes  2  MB  of  RAM  for  telemetry  buffering.  The  FPGA  provides  the  algorithm 
by  which  the  PC&T  core  provides,  power  up  &  reset  control,  command  processing, 
L/V  separation  switches,  communications,  telemetry  gathering,  telemetry  & 
command  storage,  and  ground  support. 


C&DH  Module  -  Version  II 


>  Version  II  adds  a  microprocessor 
board  to  the  Version  I  module 

>  Designed  for  applications  such  as: 


Power  Bus 
■  Ethernet 
•  12C 


S/C  Bus 


•  Space  Experiment  Testbed 

•  Escort 

•  Tactical  GPS 


-Signal 
*  Power 


Avionics  Version  II 


►  Ethernet 

►  RS-232 


■  Sep 

SOTS 


Avionics 

Sensors 


JEM  (Integrated 
Electronics ;  1 


:|;l;  -4 

▼ . . . 1 . 1... 

Cow 

Electronics 

Proa 

80 

XI . 

w*or 

itlilllll; 

l  "  t  5 

Li _ 

_  Ji- 

1 

Memory  Mapped  Bus 


Software 

Development 
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Version  II  of  the  SCOUT  avionics  will  add  a  processor  board  to  the  avionics 
subsystem;  the  rest  of  the  subsystem  (core  electronics  board)  will  remain 
unchanged. 


With  a  microprocessor  present,  autonomy  can  be  added  to  the  spacecraft;  it  will 
also  be  feasible  to  perform  complex  operations  such  as  those  required  for  G&NC 
operations.  This  version  of  the  C&DH  module  will  provide  64  to  256MB  of  ECC 
protected  mass  memory. 


C&DH  Module  -  Version  II  Block  Diagram 
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SCOUT’s  single  board  computer  is  based  on  the  Motorola  MCF5307  Coldfire 
processor.  The  MCF5307  is  a  widely  used  embedded  processor  which  provides  a 
standard  memory  interface  bus,  DRAM  controller,  I2C  interface  and  serial 
interfaces.  Memory  is  connected  to  the  processor  through  a  Memory/EDAC 
controller  which  will  be  custom  designed  into  an  Actel  FPGA.  The  memory/EDAC 
controller  will  support  boot  ROM,  Flash  memory  and  DRAM  (with  help  from  the 
MCF5307  DRAM  controller).  The  local  memory  bus  will  be  brought  off  card  to 
allow  the  processor  to  access  peripherals  on  other  parts  of  the  system.  DEBUG 

The  single  board  computer  will  also  provide  an  802.3  (Ethernet)  interface  for  debug 
and  communication  to  other  peripherals.  The  802.3  interface  will  be  based  on 
Standard  Microsystems  LAN91C96  Ethernet  MAC/PHY.  The  LAN91C96  does  not 
need  a  PCI  bus  and  provides  direct  interfacing  to  the  MCF5307  through  the  local 
memory  bus. 

The  MCF5307  has  two  configurable  UARTS.  These  UARTS,  with  the  help  of 
external  logic,  can  be  configured  as  an  RS-232,  RS-422,  or  CAN  bus  interface. 

These  serial  channels  will  be  brought  off  card  to  interface  with  other  spacecraft 
peripherals  or  for  testing  purposes.  The  single  board  computer  will  provide  a  direct 
interface  to  the  MCF5307  debug  port  for  system  testing.  Additionally  we  are 
bringing  the  MCF5307  processor’s  I2C  bus  off  card  to  interface  with  peripherals 
such  as  analog  to  digital  converters,  digital  to  analog  converters  and  EEPROM. 

Other  functions  will  include  power-on-reset,  watchdog  timer,  and  real-time  clock 


3} 
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C&DH  Module  -  Version  II  Microprocessor 


>  The  Motorola  Coldfire  MCF5307 
is  a  low-power,  highly  integrated 
processor  designed  for 
embedded  control  applications 

>  On  Chip  Features: 

•  8  KB  of  unified  cache 

•  4  KB  of  SRAM 

•  MAC  module 

•  Hardware  divide 

•  4-channel  DMA  controller 

•  DRAM  controller  with 
glueless  support  for  256  MB 
of  synchronous,  EDO  or 
page-mode  DRAMs 

•  Dual  16-bit  general-purpose 
multimode  timers 

•  Serial  and  parallel  comm 
interfaces 

•  l2C  compatible 
Motorola  M-bus 

•  Power  management  modes 

>  A  Radiation  -  Hardened  version 
is  under  development 


-  *  \  - 
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The  MCF5307  is  a  low-cost,  highly  integrated  microprocessor,  designed  for 
embedded  control  applications,  which  combines  a  ColdFire®  processor  core  with  a 
Multiply  Accumulate  (MAC)  unit,  DRAM  controller,  DMA  controller,  timers,  and 
parallel  and  serial  interfaces.  The  MCF5307  provides  interfaces  to  8-,  16-,  and  32- 
bit  DRAM,  SRAM,  ROM,  and  I/O  devices.  ColdFire®  5307  offers  a  great  deal  of 
functionality  making  it  well  suited  for  applications  such  as  micro  and  nano¬ 
satellites.  Its  power  draw  is  less  than  1W  making  the  5307  a  good  choice  for  a  very 
low  power  avionics  flight  computer.  Some  of  the  on-chip  features  include; 


•8  Kbytes  of  unified  cache 
•4  Kbytes  of  SRAM 
•MAC  module 
•Hardware  divide 
•4-channel  DMA  controller 

•DRAM  controller  with  glueless  support  for  up  to  256  Mbytes  of  synchronous,  EDO 
or  page-mode  DRAMs 

•Dual,  16-bit  general-purpose  multimode  timers 
•Serial  and  parallel  communication  interfaces 
•I2C  compatible,  Motorola  M-bus 
•Power  management  modes 


C&DH  Module  -  Version  III 


>  Version  III  is  designed  for  high 
data  volume  applications  such  as: 
•  Hi-Resolution  or  high  frame 
rate  imaging 
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For  those  applications  that  requires  great  amounts  of  mass  storage;  a  version  of  the 
avionics  has  been  devised  that  offer  up  to  an  additional  1GB  of  ECC  protected 
RAM.  Another  Idea  that  we  are  studying  is  to  have  a  mass  memory  module  that 
could  contain  several  mass  memory  cards. 


SCOUT  Mechanical  Concept 


•  9  Modules 

•  Cross  section: 

25  cm  X  25  cm 
(excluding  thrusters 
and  solar  arrays) 

•  Height:  46.7  cm 
(excluding  PAF 
Interface) 

•  Approx  mass:  63  kg 
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The  SCOUT  mechanical  concept  will  be  demonstrated  by  assembling  a  spacecraft 
with  the  SCOUT  slices.  The  particular  spacecraft  depicted  here  is  for  a  9  module 
configuration  for  a  height  of  46.7  cm  and  a  mass  of  approximately  55  kg.  Each 
module  has  a  cross  section  of  25  cm  X  25  cm.  The  modules  are  stacked  vertically 
with  any  peripheral  features  like  solar  arrays,  thrusters,  and  sensors  violating  the 
25cm  square  envelope. 


There  are  a  few  rules  about  the  order  to  stack  the  modules: 

1 .  Any  propulsion  should  be  placed  as  far  from  the  center  of  gravity  as  possible. 

2.  The  top  module  position  is  allocated  to  the  payload.  This  position  allows  for  the 
most  external  surface  area  to  accommodate  any  sensors  or  cameras  associated 
with  the  payload. 

3.  Even  though  the  modules  are  designed  to  be  independent,  there  must  be  some 
consideration  to  keep  the  peripheral  features  from  interfering.  As  seen  here,  the 
stowed  solar  arrays  and  the  thrusters  must  be  coordinated  to  avoid  interference. 


SCOUT  Standard  Module 
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•  Standard  module  contains  features 
common  to  all  modules 

•  Same  mechanical  interfaces 

•  Same  electrical  interfaces 

•  2  cm  height  increments 


|  Structure  Mass  Estimate 

Slice 

Mass 

2cm 

1.15  kg 

4cm 

1 .30  kg 

6cm 

1.45  kg 

8cm 

1.60  kg 
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Shown  here  is  an  example  of  the  standard  SCOUT  module.  Each  module  will 
contain  identical  mechanical  and  electrical  interfaces.  One  of  the  features  of  this 
design  approach  is  that  slices  can  be  assembled  in  in  any  order  (with  a  few 
exceptions)  that  will  best  meet  specific  mission  requirements. 


SCOUT  Mechanical  Interface 


•  Standard  fastener 
is  a  male/female 
threaded  adaptor 

•  Modules  attached 
at  corners  by  use  of 
standard  fastener 


Each  module  is 
attached  to  the 
module  below  it 


Standard  Fasteners 
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Mechanical  interfaces  consist  of  four  male/female  threaded  adaptors,  one  on  each 
comer  of  the  module.  Each  module  is  integrated  to  the  module  below  it  as  shown. 


SCOUT  Electrical  Interface 


Electrically,  each  module  has  a  base  and  a  top  MDM  37  contact  connector.  The 
pins  of  the  base  connector  are  connected  directly  to  the  corresponding  pins  on  the 
top  connector.  Wires  from  the  filter-thru  terminals  are  then  tapped  into  the  harness 
where  appropriate.  Once  all  the  connections  have  been  made,  a  removable  access 
panel  is  bolted  in  place  to  protect  the  wiring  harness. 


On  occasion,  there  is  a  need  for  a  model  to  be  rotated  90°.  These  module  will  be 
equipped  with  a  second  base  connector. 


Module  1 :  RAF  Interface  Module  (RIM) 


PIM  stays  with  SCOUT 


AeroAstro 


Page  8 


The  first  module  of  the  S/C  is  the  PAF  Interface  Module  which  consists  of: 
•The  separation  system.  In  this  case  it  is  a  standard  15”  Lightband. 

•An  Adaptor  Cone  to  reduce  the  size  of  the  bolt  pattern  to  correspond  to  the  25 
cmA2  SCOUT  cross  section 

•A  Bolt  Pattern  Adaptor  to  allow  the  next  module  to  attach  with  the  standard 
SCOUT  fastener. 


Module  2  is  the  lower  propulsion  module.  The  propulsion  module  is  a  welded 
titanium  pressure  vessel  with  a  ceramic  thruster  nozzle  on  two  opposing  comers. 
This  is  one  of  the  modules  that  requires  a  second  base  connector  for  rotation. 


Module  3:  Solar  Arrays 


«„  v»  Ae  ro Astro 


Module  3  is  the  solar  array  module.  The  array  technology  that  will  be  used  has  not 
been  selected.  An  issue  with  the  ridged  panels  (shown)  is  that  they  can  not  be  held 
in  the  stowed  position  without  help  from  a  second  module  located  higher  up  on  the 
stack  of  modules.  One  of  the  concepts  of  SCOUT  is  that  the  modules  are  designed 
to  be  completely  independent  from  the  rest  of  the  spacecraft.  Other  technologies 
that  may  be  a  better  fit  for  SCOUT  are  flexible  arrays  that  roll  up  on  each  side,  and 
inflatable  array  structures.  The  array  module  will  also  be  equipped  with  any  shunt 
electronics  that  are  needed. 


Module  4:  Battery 


Module  4  is  the  battery  pack.  The  module  we  are  using  can  hold  up  to  four  24  cell 
batteries  complete  with  their  charge  electronics. 


Module  5  is  allocated  to  command  and  data  handling.  The  concept  for  this  module 
is  to  include  secondary  structure  in  the  form  of  a  removable  VME  cage.  This  allows 
the  boards  to  be  integrated  and  tested  easily  while  still  allowing  for  access  to  all 
boards.  After  all  testing  is  completed,  the  entire  VME  cage  assembly  is  dropped 
into  the  primary  module  structure  and  bolted  in  place. 


Module  6:  Attitude  Determination 


Contains  all  attitude 

determination 

components 

Gyrochip  Array 


ADS  Electronics 


4  Star  Trackers 


4  Sun  Sensors 
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The  attitude  determination  module  (Module  6)  contains  all  the  instruments  needed 
for  attitude  determination  along  with  the  electronics  and  software  required.  The 
module  shown  here  contains  star  trackers,  sun  sensors,  and  gyrochips. 


Module  7:  RF  Communications 


Module  7  contains  the  equipment  for  RF  communications.  The  components  shown 
are  from  the  NMRF  transponder  that  is  being  developed  by  AeroAstro.  All 
antennas  needed  will  be  included  in  this  slice  (patch  antennas  are  shown). 


The  upper  propulsion  module  is  identical  to  the  lower  propulsion  module  but  it  is 
rotated  90°.  Notice  that  the  propulsion  modules  are  as  far  away  from  the  spacecraft 
CG  as  possible. 


Module  9:  Payload 


The  Payload  Module  is  custom  configured  for  each  application 
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Module  9  is  the  uppermost  module  and  as  such  is  reserved  for  the  payload.  This 
module  can  be  configured  as  to  meet  the  customer’s  needs  as  long  as  all  electronics 
communications  entering  and  leaving  the  module  are  SCOUT  compatible. 
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This  mass  budget  shows  the  approximate  mass  for  this  SCOUT  based  mission. 


SCOUT  Structure  Analysis 


All  Wall  Thicknesses:  0.060” 

Material:  Al  6061-T6 

Static  Loads:  13  Gs  in  any  axis 

Stiffness  Requirement:  40  Hz 

Nonstructural  mass 
evenly  distributed 

Analyzed  S/C  Mass:  75  kg 

Analyzed  S/C  Envelope: 

25  cm  X  25  cm  X  50  cm 
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Structure  analysis  was  done  with  Patran/Nastran.  The  model  assumes  that  the  slices 
are  fastened  together  in  such  a  way  that  the  spacecraft  behaves  as  if  it  were  made 
from  a  solid  piece  of  aluminum.  All  walls  were  assumed  to  be  0.060”  thick.  Static 
loads  and  stiffness  requirements  were  determined  to  accommodate  most  existing 
launch  vehicles.  All  non-structural  mass  was  distributed  evenly  throughout  the 
spacecraft. 


SCOUT  Stiffness  Results 


•  Stiffness  increases  directly 
with  baseplate  thickness 

•  Stiffness  Requirement:  40  Hz 


Baseplate 

Thickness 

Frequency 

0.060” 

69  Hz 

0.200” 

165  Hz 
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The  stiffness  analysis  shows  that  the  structure  is  in  compliance  with  the  stiffness 
requirement  of  40  Hz.  It  is  important  to  note  that  the  frequency  is  directly  related  to 
the  baseplate  thickness.  This  means  that  if  the  stiffness  needs  to  increase,  the  only 
thing  that  must  be  changed  is  the  baseplate.  This  allows  SCOUT  to  be  a  truly 
modular  design  because  regardless  of  the  launch  environment  or  the  mass  of  the 
spacecraft,  the  structure  of  the  individual  modules  do  not  need  to  be  modified. 


Stress  results  are  similar  to  the  stiffness  results.  Again  notice  that  the  stress  margin 
increases  directly  with  the  baseplate  thickness. 


SCOUT  Thermal  Analysis 


Spacecraft  analyzed  as  a  point  mass 
Thermal  Mass:  20  kg  (structure  mass) 


Absorbed 

Radiation 


•  Coating:  Black  Anodize  (0.86,0.86) 

•  Maximum  Temperature:  +  18.5°  C 

•  Minimum  Temperature:  -  4.5°  C 


55  watts  dissipated 
(orbit  average) 
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A  preliminary  thermal  analysis  was  conducted  on  SCOUT.  The  spacecraft  was 
analyzed  as  a  point  mass  with  a  thermal  mass  of  20  kg  (approximate  structure 
mass).  Radiation  absorbed  and  emitted  was  estimated  using  the  surface  area  and  the 
thermal  properties  of  a  black  anodize  coating.  Internal  heat  generation  was 
estimated  at  55  watts.  This  thermal  system  was  cycled  though  a  typical  GTO 
sunlight/eclipse  cycle  to  find  the  maximum  and  minimum  temperatures. 


C'V;  Aero  Astro 

System  Overview 

Glen  Cameron 

Glen,  CamerondobAe  roAstro.com 
703-723-9800  Ext.  159 


This  presentation  provides  an  overview  of  the  SCOUT  microsatellite  architecture 
with  a  focus  on  the  characteristics  of  a  SCOUT  vehicle  configured  to  fulfill  the 
Escort  mission. 


Key  SCOUT  Design  Feature:  Modularity 


•  The  SCOUT  system  hinges  on  the  adoption  of  uniform  mechanical  and 
electrical  interfaces  to  allow  continuous  expansion  of  the  envelope 

•  Another  key  feature  of  SCOUT  is  that  the  housing  serves  as  the  structure 
-  this  avoids  the  need  to  develop  a  custom  framework  for  each  mission 

•  This  uniform  housing  provides  rigidity  and  strength  and  also  serves  as  a 
thermally  conductive  path  to  isothermalize  the  spacecraft  bus 

•  A  standard  field  joint  allows  any  module  to  interface  to  any  other  module 

•  Each  module  has  a  "pass-through"  electrical  connector  in  a  standard 
location  that  provides  power,  low  speed  data,  and  high  speed  data  to  and 
from  each  module  for  flexible  standard  "backbone"  data  interfaces 

•  This  uniform  electrical  interface  provides  the  ability  to  test  any  module  in 
the  field  using  the  Master  Universal  Ground  Support  Equipment 


Modularity  enables  the  Flexibility,  Field  Configurability, 
Scalability „  and  Extensibility  of  the  SCOUT  Systern 
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The  key  to  meeting  the  SCOUT  requirements  for  flexibility,  field  configurability, 
scalability,  and  extensibility  is  MODULARITY.  It  is  virtually  impossible  to  meet  all 
of  these  goals  without  a  modular  spacecraft  bus  architecture.  The  SCOUT  modular 
architecture  starts  with  a  uniform  mechanical  and  electrical  interface  that  is 
common  to  all  modules.  This  common  interface  provides  the  framework  for 
realizing  an  extensive  set  of  potential  modules  that  can  be  combined  in  nearly 
limitless  combinations  to  tailor  a  SCOUT-based  vehicle  to  meet  a  single  set  of 
unique  requirements. 


As  the  uniform  mechanical  interface  evolved,  it  gave  rise  to  several  features  which 
became  core  elements  of  the  common  mechanical  design.  The  housing  of  the 
SCOUT  module  doubles  as  the  SCOUT  load-bearing  structure,  so  there  is  no 
requirement  for  a  separate  primary  or  skeletal  structure.  The  SCOUT  modular 
housing  is  referred  to  as  the  EXOSKELETON,  which  provides  both  enclosure  and 
structure  in  a  single  element.  This  robust  structure  is  stiffened  with  rib  features  to 
provide  an  extremely  stiff,  strong,  load-bearing  capability.  This  structure  also  serves 
as  a  thermally  conductive  sink  for  dissipating  heat  from  the  enclosed  SCOUT 
electronics.  Assuming  that  this  structure  is  aluminum,  this  highly  conductive 
housing  serves  to  isothermalize  the  bus,  spreading  excess  heat  from  those  modules 
which  dissipate  high  power  levels  to  those  modules  which  are  inherently  low-power 
devices.  This  standard  field  joint  is  intended  to  allow  any  given  module  to  mate  to 
any  other  module.  This  feature  provides  tremendous  flexibility  in  the  topology  of  a 
selected  bus. 


Each  module  has  a  "pass-through"  electrical  connector  in  a  uniform  location;  this 


Notional  SCOUT  Modules  (1  of  2) 
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The  Mission  Study  conducted  in  the  opening  weeks  of  the  Phase  I  SBIR  effort 
identified  three  leading  contenders  for  candidate  SCOUT  missions.  These  missions 
were  the  SCOUT  Escort  (described  previously),  the  SCOUT  Tactical  GPS  (used  to 
augment  or  temporarily  substitute  for  operational  GPS  satellites),  and  the  SCOUT 
Tech  Dem-Val  (a  general  purpose  SCOUT  spacecraft  used  for  testing  new 
technologies  in  space).  In  the  Dem-Val  scenario,  SCOUT  serves  as  a  vehicle  to  gain 
flight  heritage,  i.e.,  to  prove  that  a  payload  or  subsystem  can  survive  launch  and 
operate  in  space.  In  some  cases,  limited  on-orbit  operations  are  required. 

For  each  of  these  three  missions,  a  notional  concept  was  quickly  developed  to 
identify  the  SCOUT  modules  that  would  be  required  to  realize  each  version  of 
SCOUT.  This  chart  (and  the  following  chart)  summarizes  the  results  of  this  survey. 
The  goal  of  these  charts  is  to  identify  "common"  modules  and  differentiate  them 
from  "mission  unique"  modules.  Some  entries  may  be  misleading  or  confusing, 
however,  so  we  will  quickly  review  this  table. 

This  chart  shows  that  the  Technical  Demonstration-Validation  mission  (TDV) 
requires  only  an  Avionics  I  Module,  the  Tactical  GPS  mission  (TGPS)  requires  an 
Avionics  II  module,  and  the  Escort  mission  requires  an  Avionics  III  module.  This 
leads  to  an  impression  that  there  is  no  "common"  avionics  module,  howver,  this  is 
NOT  the  case.  The  Avionics  I  module  is  a  subset  of  the  Avionics  II  module,  and  the 
Avionics  II  module  is  a  subset  of  the  Avionics  III  module.  Therefore,  the  Avionics  I 
module  is  common  to  all  three  missions  and  the  Avionics  II  module  is  used  by  two 
out  of  three  missions.  Furthermore,  upon  closer  examination,  it  was  concluded 
during  the  conceptual  design  effort  that  Escort  only  requires  an  Avionics  II  module. 


Notional  SCOUT  Modules  (2  of  2) 
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This  chart  shows  that  all  three  missions  would  use  the  rechargeable  chemical  battery 
module,  which  is  nominally  a  Lithium  Ion  battery.  The  early  concept  for  the  battery 
module  assumed  an  8cm  tall  module  that  housed  one  to  four  "battery  packs"  that 
allow  the  user  to  scale  the  battery  capacity  to  the  mission.  A  more  recent  concept 
envisions  a  2  cm  tall  battery  module  that  is  completely  self-contained.  In  this 
concept,  individual  battery  modules  are  incorporated  in  sufficient  number  to  meet 
energy  storage  requirements.  Better  definition  of  the  battery  module(s)  for  each 
mission  would  require  a  better  knowledge  of  the  required  capacity. 

The  chart  also  shows  that  all  three  missions  would  require  the  Solar  Panel  Array 
module.  While  it  is  clear  that  all  would  require  some  sort  of  solar  array,  it  is  not 
assured  that  all  three  would  require  the  exact  same  module.  Scalability  of  the  solar 
array  module  is  still  being  studied;  as  a  more  scalable  design  is  developed,  there 
may  be  greater  differentiation  between  these  missions  with  regard  to  selection  of  the 
solar  array  module. 


For  purposes  of  this  study,  it  was  assumed  that  four  different  variants  of  the  Payload 
Attach  Fitting  Interface  Module  (PIM)  would  be  developed.  This  chart  shows  that 
the  Escort  and  TDV  vehicles  would  both  be  launched  using  an  ESPA  PIM  and  that 
the  TGPS  vehicle  would  launch  on  a  RASCAL  PIM.  In  fact,  no  firm  requirement 
exists  for  any  of  these  missions;  the  actual  selection  of  the  PIM  would  be  subject  to 
Launch  Vehicle  selection.  The  important  point  is  that  the  PIM  does  not  have  to  be 
selected  until  shortly  before  launch.  In  fact,  the  PIM  can  be  changed  after 
integration  if  there  is  a  change  in  Launch  Vehicle. 


SCOUT  Modules  for  Escort 

•  Payload 

•  Communications  Transponder 

•  Attitude  Determination 

•  Avionics  II 

•  Storage  Battery 

•  Solar  Array 

•  Propulsion  (2) 

•  LV  Payload  Attach  Fitting  Interface 
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This  chart  details  the  precise  modules  envisioned  for  the  Escort  version  of  SCOUT 
as  conceived  dining  the  Conceptual  Design  phase  of  the  SBIR.  The  details  relating 
to  each  module  are  discussed  below. 


At  the  bottom  of  the  SCOUT  stack  is  the  LV  Payload  Attach  Fitting  Interface 
Module,  or  PIM.  This  module  provides  the  mechanical  interface  between  the 
SCOUT  Escort  Vehicle  and  the  Launch  Vehicle  (LV).  The  selection  of  PIM  is 
dependent  upon  the  selection  of  LV,  i.e.,  there  is  a  unique  PIM  for  each  type  of 
Launch  Vehicle.  The  PIM  also  provides  an  electrical  interface  between  the  LV  and 
the  SCOUT  Escort  for  detecting  separation  (only).  Regardless  of  LV,  the  unique 
separation  signal  from  each  LV  is  translated  to  a  uniform  signal  on  the  SCOUT 
Backbone.  This  Backbone  signal  is  a  fault-tolerant  2-for-3  voting  scheme  designed 
to  provide  assured  knowledge  of  the  separation  event  to  the  SCOUT  Vehicle.  The 
SCOUT  Escort  Vehicle  uses  this  signal  to  begin  its  on-orbit  initialization  process. 
There  is  no  other  electrical  connection  to  the  Launch  Vehicle,  i.e.,  SCOUT  cannot 
recharge  it's  battery  or  provide  umbilical  telemetry  to  the  LV.  This  avoids  a 
significant  level  of  time-consuming  interaction  that  accompanies  development  of  a 
typical  LV  Interface  Control  Document.  More  detail  about  the  PIM  is  provide  in 
Section  05. 


The  next  module  on  the  stack  is  the  first  of  two  Propulsion  Modules.  Details  of  the 
Propulsion  Module  will  be  provided  in  Section  10.  For  now,  suffice  it  to  say  that 
this  module  uses  two  four- way  ceramic  thruster  nozzles  located  on  opposite  comers 
of  the  module.  Nitrous  Oxide  has  been  selected  as  a  propellant  due  to  its  properties 
as  a  safe,  storable  liquid.  The  Nitrous  Oxide  is  stored  inside  of  the  Propulsion 


Escort  Block  Diagram 


This  chart  shows  a  Block  Diagram  of  the  SCOUT  Escort  vehicle.  Each  of  the 
modules  described  in  the  previous  chart  are  depicted  functionally  in  this  diagram. 
Additionally,  this  diagram  shows  the  interconnecting  SCOUT  Backbone  bus  that 
allows  each  module  to  communicate  and  draw  power.  It  can  be  seen  that  the 
Backbone  bus  provides  three  interfaces:  power;  low-speed  data;  and  high-speed 
data.  More  detailed  information  about  the  Backbone  bus  is  available  in  Section  06. 

The  power  bus,  shown  in  red,  connects  to  every  module.  The  Solar  Array  module 
sources  power  to  the  power  bus  when  the  arrays  are  illuminated.  The  Battery 
Module  takes  power  from  the  power  bus  when  the  arrays  are  producing  excess 
power  (storing  the  energy  in  Lithium  Ion  batteries),  and  sources  power  to  the  bus 
when  the  arrays  are  not  capable  of  supplying  sufficient  power.  All  of  the  other 
modules  take  power  from  the  power  bus.  Power  switching  is  done  locally  in  each 
module  as  commanded  via  the  low-speed  data  bus. 

The  low-speed  data  bus,  shown  in  green,  also  connects  to  every  module.  This  data 
bus,  capable  of  handling  data  rates  up  to  400  kbps,  is  used  for  sending  commands  to 
each  module  and  sharing  low  speed  telemetry  data  from  one  module  to  the  next. 
Data  is  transmitted  on  this  bus  using  the  Inter-Integrated  Circuit  (I2C)  data 
communications  standard. 

The  high-speed  data  bus,  shown  in  blue,  only  connects  to  selected  modules.  This 
bus  is  capable  of  handling  data  rates  up  to  10  Mbps  using  the  IEEE  803.2  (Ethernet) 
data  communications  standard.  For  Escort,  it  is  anticipated  that  only  the  Attitude 


Payload  Attach  Fitting 
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This  image  depicts  the  deployed  configuration  of  the  SCOUT  Escort  Vehicle.  It 
shows  the  location  and  orientation  of  all  modules  described  on  page  5  of  this 
presentation,  as  well  as  the  location  and  deployed  configuration  of  the  solar  arrays, 
thrusters,  and  antennas.  What  is  not  communicated  in  this  view  is  a  sense  of  the 
scale  of  the  vehicle,  which  is  actually  fairly  small.  Note  that  the  scout  modules  are 
each  25  cm  X  25  cm  (10"  X  10"),  with  heights  varying  from  2  cm  to  8  cm. 


SCOUT  Stowed  Configuration  for  Escort 


This  graphic  depicts  the  top,  side,  and  orthographic  views  of  the  stowed  SCOUT 
Escort  vehicle.  Looking  down  from  the  top  of  the  vehicle,  it  can  be  seen  that  the 
protruding  thrusters  on  the  comers  of  the  two  propulsion  modules  must  be 
accounted  for  in  the  layout  of  the  stowed  solar  arrays.  The  overall  vehicle  height  is 
less  than  50  cm  (20"),  not  including  the  Payload  Attach  Fitting.  At  25  cm  X  25  cm 
X  50  cm,  the  SCOUT  Escort  microsatellite  is  about  the  size  of  an  office 
wastebasket. 


SCOUT  Performance  Summary  for  Escort 


Space  Vehicle  (SV)  Dry  Mass  (w /  25%  margin): 

55  kg 

Orbit  Average  (OA)  SV  Power  (w/  25%  margin): 

42  W 

Payload  Mass  (w/  25%  margin): 

5  kg 

OA  Payload  Power  (w/  25%  margin): 

2  W 

Pointing  Knowledge  (3-axis,  3a): 

0.5  deg 

Pointing  Control  (3axis,  3a): 

1 .5  deg 

Mission  Lifetime: 

1  year 

Orbit: 

GEO 

Downlink  Data  Rate: 

76.8  kbps 

Uplink  Data  Rate: 

2  kpbs 

On-Board  Data  Storage: 

256  MB 
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This  chart  summarizes  the  high  level  performance  characteristics  of  the  SCOUT 
Escort  microsatellite.  This  configuration  of  SCOUT  shows  a  dry  mass  of  55  kg 
including  25%  margin  (typical  for  a  conceptual-level  design)  and  an  orbit  average 
power  consumption  of  42  watts,  also  including  a  25%  margin.  Of  this  total,  5  kg  and 
2  watts  are  allocated  for  the  payload.  It  is  observed  that  these  mass  and  power 
fractions  would  not  be  considered  very  commendable  for  a  typical  custom-designed 
satellite.  There  are  several  mitigating  factors  to  consider  when  examining  this 
metric,  however.  First,  There  is  a  mass  and  power  penalty  associated  with  the 
modularity  of  the  design;  a  general-purpose  modular  spacecraft  is  never  going  to  be 
as  mass  and  power  efficient  as  a  typical  custom  design.  Second,  this  design  includes 
a  great  deal  of  margin  due  to  the  very  modest  level  of  effort  expended  on  analysis  to 
date;  it  is  anticipated  that  these  very  conservative  mass  and  power  numbers  will  be 
reduced  as  the  design  is  detailed.  The  pointing  knowledge  is  expected  to  be  better 
than  0.5  degrees,  with  a  pointing  control  of  better  than  1.5  degrees.  The  vehicle  is 
expected  to  have  a  mission  life  of  better  than  one  year  in  GEO,  however,  ultimate 
mission  life  would  be  limited  by  the  frequency  and  magnitude  of  propulsive 
maneuvers,  i.e.,  the  vehicle  will  ultimately  be  propellant-limited.  The  Downlink 
data  rate  (from  GEO)  will  be  76.8  kbps  assuming  a  transmit  power  of  1.5  watts.  It  is 
possible  to  increase  transmit  power  and  therefore  downlink  data  rate  at  the  expense 
of  power  consumption.  The  uplink  data  rate  is  sized  at  2  kbps.  The  onboard  data 
storage  is  limited  to  256  MB  using  the  Avionics  II  C&DH  module.  An  Avionics  III 
module  would  have  considerably  more  data  storage  (with  associated  mass,  power, 
and  dimensional  impacts),  however,  data  volume  is  ultimately  limited  by  the 
downlink  data  rate  and  the  time  associated  with  dumping  data. 
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SCOUT  Requirements  Basis 


>  Usually,  requirements  are  based  on  a  single  mission 

> SCOUT  requirements  are  developed  on  the  basis  of: 

•  Applicability  to  a  broad  range  of  missions; 

•  Low  recurring  cost; 

•  Low  mass  and  small  volume; 

•  Scalability  and  Extensibility; 

•  Rapid  response; 

•  Easy  field  assembly 

>  All  requirements  must  be  consistent  with  identified 
boundary  conditions,  e.g.,  Launch  Vehicle  constraints 

>  Additional  requirements  are  levied  for  the  Escort  mission  as 
a  case  study  to  validate  the  SCOUT  conceptual  design 
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In  other  words,  SCOUT  requirements  are,  in  a  sense,  worked  backwards.  Rather 
than  optimizing  a  bus  to  a  specific  mission,  SCOUT  provides  a  low-cost  bus  that 
can  handle  a  multitude  of  missions,  and  assumes  that  payload  providers  are  willing 
to  subject  their  instruments  to  SCOUT  interfaces  (thermal,  mechanical,  electrical). 
To  prove  the  utility  of  the  bus,  AeroAstro  applied  a  very  strenuous  mission  to  it  - 
the  Escort  payload  monitoring  a  GEO  primary  spacecraft.  The  listed  requirements 
on  this  document  apply  to  the  Escort  mission. 


SCOUT  Boundary  Conditions 


>  Identified  boundary  conditions  are: 

•  Launch  Vehicle  compatibility 

•  Restrictions  of  the  SCOUT  module  architecture  which  affect: 

-  Component  size 

-  Component  placement 

-  Thermal  Limits 

-  Power  Limits 

-  Subsystem  component  selection  which  affects  performance 

■  Propulsion 

■  Attitude  Determination  and  Control 

■  Communications  (link  budgets) 
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These  are  the  boundary  conditions  that  ultimately  limit  SCOUT  performance,  and 
thus  the  missions  it  can  support. 

Launch  vehicle  compatibility  limits  spacecraft  volume  and  mass,  as  well  as  the  orbit 
that  can  be  attained. 

Component  selection  is  limited  by  what  can  fit  into  the  volume  restrictions  of  a 
SCOUT  module,  what  is  satisfied  by  the  SCOUT  power  and  data  provisions,  and 
what  can  operate  within  the  SCOUT  thermal  environment. 

Component  selection  inherently  limits/defines  subsystem  performance. 


Requirements  Development 


>SCOUT  subsystem  requirements  are  flowed  down  from 
restrictions  imposed  by: 

•  Launch  Vehicle  envelopes  and  capabilities: 

•  Selection  of  modular  architecture; 

•  Escort  payload  instrumentation 

>25%  margins  have  been  applied  to  all  requirements 
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The  requirements  presented  here  take  the  aforementioned  boundary  conditions  into 
account,  then  further  define  them  by  application  of  the  Escort  payload 
specifications. 


Launch  Vehicle  Restrictions* 


5.2  Launch  Vehicle  Requirements 

5.21  Maximum  Space  Vehicle  Mass: 

75kg 

5.22  Maximum  Envelope: 

5.22.1  Height 

500  mm 

5.22.2  Width 

440  mm 

5.22.3  Depth 

440  mm 

|  5.23  Minimum  Fundamental  Frequencies:  | 

5.23.1  Axial 

50  Hz 

5.23.2  Lateral 

40  Hz 

5.23.3  Torisional 

50  Hz 

1  5.24  Maximum  Quasi-static  Loads:  1 

5.24.1  Axial 

13G 

5.24.2  Lateral 

2.5G 

*Condensed  from  Launch  Vehicle  study  submitted  17  APR  03 
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SCOUT  Launch  Vehicle  Compatibility 

>By  satisfying  these  restrictions,  a  SCOUT-based  spacecraft 
would  be  compatible  with  requirements  for  launch  on: 

•  Ariane  4  and  5  •  Minotaur 

•  Atlas  II,  III,  and  V  •  Pegasus 

•  Delta  II,  III,  and  IV  •  RASCAL 

•  Eurockot  •  Sealaunch 

•  H-IIA  •  STS 

•  K1  •  Taurus 

•  Kosmos 


Modularity  Derived  Requirements 


>Each  SCOUT  module  will  be  25  x  25  cm  x  Z  cm 
(where  Z  is  a  multiple  of  2,  e.g.,  2,  4,  6,  8,  etc.) 

>Each  module  is  completely  self-contained 
>Each  module  will  pass  through  and  have  access  to: 

•  Power  and  electrical  ground 

•  Low  speed  data 

•  High  speed  data 

>Connectors  will  enforce  correct  stacking  of  modules  during 
assembly;  some  modules  (e.g.,  propulsion)  are  rotatable 

>MUGSE  testing  will  be  modularized 
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RF  Probe  Specifications 


Component  Specifications 

Full  Width  Half  Power  angle  (deg) 
Mass  (kg) 

Dimensions  (cm) 

Power  Consumption  (W) 

30 

1.50 

17.8x8.9x6.2 

6 

Performance 

Max  Data  Rate  (kbps) 

Nominal  Data  Rate  (kbps) 
Frequency  Response 

Control  Electrical  Interface 

2000 

30 

50  KHz  to  18  GHz 

RS-422 

Environment 

Operating  Temp  Range  (deg  C) 

-20  to  +70 

Visible  Camera  Specifications 


Laser  Range  Finder  Specifications 


Subsystem  Requirements* 


Req.  Description 

Value 

Units 

Orbit  Determination  &  ADCS 

Perigee  altitude 

35,800 

km 

Apogee  altitude 

35,800 

km 

Inclination 

~0 

deg 

Inertial  orbit  determination  accuracy 

+/- 1 

km 

Relative  orbit  determination  accuracy 

+/-10 

m 

*Note:  These  are  mission  specific  requirements  for  the  Escort  payload 
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For  the  Escort  type  mission,  SCOUT  will  require  a  geosynchronous  orbit  with  an 
inclination  that  approximately  matches  the  target,  near  zero.  Ground  ranging  must 
meet  an  accuracy  of  +/-  1  km  and  laser  ranging  to  the  target  must  meet  +/-  10  meter 
accuracy. 


Subsystem  Requirements  (Cont'd)* 


.  . 11,1 . 

Req.  Description 

MB— 

Units 

Attitude  and  Proximity  Maneuvering 

Pointing  control  roll 

1.5 

deg 

Pointing  control  pitch 

1.5 

deg 

Pointing  control  yaw 

1.5 

deg 

Rate  control  roll 

0.127 

deg/sec 

Rate  control  pitch 

0.127 

deg/sec 

Rate  control  yaw 

0.127 

deg/sec 

Mission  lifetime  (days) 

60 

days 

Mission  duty  cycle 

ioo  ; 

% 

DV  margin 

30 

% 

*Note:  These  are  mission  specific  requirements  for  the  Escort  payload 
<rV*  Aero  Astro  p^12 


The  limiting  payload  element  for  both  pointing  and  rate  control  is  the  visual  camera. 

As  the  Escort  service  is  anticipated  to  be  an  early  mission  test  and  anomaly  analysis 
tool,  its  lifetime  is  only  required  to  be  60  days.  Note  that  the  allowable  propellant 
budget  provides  135  days,  exceeding  this  requirement  by  over  100%. 

Hibernation  could  extend  total  on-orbit  time  to  up  to  a  total  of  1  year. 


Subsystem  Requirements  (Cont'd)* 


— 

Units 

Attitude  and  Proximity  Maneuvering 

Stabilization  Method 
slew  required  for  relative  ranging 
Three-axis  translation  required? 
Translation-free  torque  required? 

Pointing  knowledge  roll 

Pointing  knowledge  pitch 

Pointing  knowledge  yaw 

Rate  knowledge  roll 

Rate  knowledge  pitch 

Rate  knowledge  yaw 

3-axis 

2  per  hour 
Yes 

Yes 

0.5 

0.5 

0.5 

0.03 

0.03 

0.03 

deg 

deg 

deg 

deg/sec 

deg/sec 

deg/sec 

*Note:  These  are  mission  specific  requirements  for  the  Escort  payload 
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Full  three  axis  stabilization  is  required  in  order  to  continue  to  correctly  point  the 
payload  as  SCOUT  moves  relative  to  the  primary. 

Orbit  control  is  three  dimensional  (three  axis  translation)  and  attitude  control  is 
required  to  be  able  to  occur  without  coupling  into  an  orbit  adjustment  (translation- 
free  torque). 

Pointing  and  rate  control  are  1/3  that  of  the  pointing  and  rate  knowledge 
requirements. 


Subsystem  Requirements  (Cont'd)" 


Power 

SV  Orbit  Average  Power  Required 

50 

Payload  Power  Required 

16 

SV  Bus  Voltage 

28  +/-  6 

Battery  Capacity 

315 

Peak  Power 

110 

Thermal 

Max  survival  temperature 

60 

Min  survival  temperature 

-15 

Max  operating  temperature 

40 

Min  operating  temperature 

0 

*Note:  These  are  mission  specific  requirements  for  the  Escort  payload 
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Orbit  Average  Power  required  is  based  on  the  operational  demands  of  the  payload 
as  well  as  the  spacecraft  bus  draw.  A  Depth  of  Discharge  of  40%  yields  the  battery 
capacity  value. 

The  thermal  requirements  are  based  on  the  Li  Ion  Battery  as  the  limiting  component 


Subsystem  Requirements  (Confd)* 


Req.  Description 

Value 

Command  and  Data 

Mass  Storage  Capacity* 

35 

MB 

Processing  Power 

40 

MIPS 

RF  Uplink  rate 

1000 

bps 

RF  Downlink  Rate 

76800 

bps 

Payload  Data  rate 

5 

Mbps 

Payload  Data  Compression 

25:1 

Time  Source  Accuracy 

200 

msec 

S/C  Telemetry  Gathering  Rate 

1 

Kbps 

Analog  lines  required 

64 

Discrete  Lines  Required 

16 

Storage  required  for  5  seconds  Visible  and  RF  Probe  at  Burst  Rates 
+  5  minutes  Visible  at  Nominal  Rate  +  55  minutes  RF  Probe  at 
Nominal  Rate.  Also  allows  downlink  in  2  hours  at  76.8  kbps  rate 


*Note:  These  are  mission  specific  requirements  for  the  Escort  payload 
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Payload  Data  Rate  -  again,  the  most  demanding  element  is  the  Visible  camera.  With 
a  Burst  Rate  of  3.35  Mbps,  plus  margin,  it  requires  a  5  Mbps  total  data  rate 
capability.  The  SCOUT  high  speed  line  capacities  of  either  10  or  100  Mbps  can 
easily  handle  this. 

Time  Source  Accuracy  requirement  is  based  on  the  relative  orbit  knowledge 
requirement  of  +/-10  meters. 

Telemetry  gathering  rate  is  based  on  typical  small  spacecraft  state  of  health  data 
collection  rates  as  is  the  Uplink  (command)  data  rate. 


Environmental  Requirements 


>Cleanliness 

•  Integrate  modules  in  a  class  100,000  clean  room 

>  Electromagnetic  Compatibility 

•  Compliant  to  Ml L-STD-461C 

>Radiation  Tolerance 

•  To  1 .25  years  at  geosynchronous  altitude 
(1  year  mission  life  plus  25%  margin) 

•  Typical  radiation  dose  is  40  krad/year  with  60  mil  Al  shielding* 

•  This  yields  a  tolerance  requirement  of  50  krad  TID 

*  Source:  Wertz,  Space  Mission  Analysis  and  Design 

r'Vj  Aero  Astro  p^ie 


Overview 


>  Characteristics  for  GEO  Spacecraft 

>  Potential  Activities  of  Interest 

>  Potential  Features  of  Interest 

>  Technical  Performance  Metrics 

>  Payload  Module  Design 

•Visual  Camera 

-  Specifications 

-  Performance 

-  Target  Illumination 

•  RF  Probe  Performance 

•  Laser  Rangefinder  Performance 
•Module  Integration 
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Characteristics  for  GEO  Spacecraft 


>  Typical  Dimensions: 

•  Length  (Solar  Panels):  30  -  50  meters 

•  Width  (Antennas):  9-17  meters 

•  Height  (Antennas):  5-8  meters 

>  Typical  Broadcast  Frequencies  (UL/DL): 

•  Commercial: 

-  L-Band:  1 .635  -  1 .66  / 1 .535  -  1 .56  GHz 

-  C-Band:  5.9  -  6.4  /  3.7  -  4.2  GHz 

-  X-Band:  7.9  -  8.4  /  7.25  -  7.75  GHz 

-  Ku-Band:  14.0  -  14.5  / 12.5  -  12.75  GHz 

•  Military: 

-  L-Band:  1 .635  -  1 .66  / 1 .535  -  1 .56  GHz 

-  S-Band:  2.65  -  2.69  /  2.5  -  2.54  GHz 

-  X-Band:  7.9  -  8.4  /  7.25  -  7.75  GHz 
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In  order  to  understand  the  characteristics  of  the  typical  GEO  spacecraft  an  Escort 
SCOUT  might  be  tasked  with  surveying,  an  investigation  was  conducted  to  envelop 
the  target  features.  The  dimensions  of  an  average  communications  satellite  are 
dominated  by  the  solar  panel  array  and  can  be  as  large  as  50  meters,  though  more 
commonly  closer  to  40  meters.  Bus  dimensions,  in  width,  usually  include  the  large 
reflectors,  that  themselves  span  diameters  that  average  3-5  meters.  Height  is  largely 
the  cross-sectional  area  of  the  bus,  with  the  addition  of  small  Earth  uplink  antennas. 
In  military  applications,  such  as  the  Milstar  spacecraft  shown,  this  height  is  much 
longer — necessary  to  accommodate  the  large  payload  complement. 


Information  for  typical  broadcast  frequencies  is  publicly  available  from  resources 
such  as  the  ITU,  FCC,  or  references  such  as  Space  Mission  Analysis  and  Design 
(Wertz). 


Potential  Activities  of  Interest 


>  Nominal  Operations 

•  Deployments 

-  Solar  arrays  (5  -  30  min) 

-  Reflectors 

QuickTime™  and  a  Cinepak  decompressor  are  needed  to  see  this  picture.  ■  Primary  (5  min  —  3  hours) 

■  Earth-Deck  (5- 15  min) 

-  Antennas,  Booms 
•In-Orbit-Test 

-  Antenna  slew  cuts  (10-30  min) 

-  Plume  wake-field  mapping  (RF) 

>  Anomaly  Response 

•  Drive  motor  stuck,  impaired 
•Thruster,  actuator  all-open/closed 

•  Errant,  foreign  RF  signals 
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Within  the  operational  lifetime  of  a  GEO  spacecraft,  there  are  a  number  of 
significant  events  that  would  greatly  benefit  from  an  observer  located  in  the  near¬ 
vicinity,  that  was  capable  of  sampling  the  events  in  the  visual  and/or  RF  domain. 
While  the  majority  of  activities  on  station  are  relatively  slow  moving  and  benign, 
certain  key,  “rapid”  moments,  such  as  deployments,  represent  critical  periods  of 
concern.  A  good  deal  of  understanding  could  be  realized,  for  example,  on  how 
certain  flexible  body  modes  are  excited  by  the  pyrotechnic  release  of  a  solar  panel 
or  the  broad  sweep  of  a  slew  cut  taken  to  define  antenna  gain  patters.  This 
information  could  be  provided  as  empirical  data  to  design  engineers  that  are 
responsible  for  specifying  hinge  damping  ratios  or  locations  of  ejector  springs.  An 
obvious  application  of  an  Escort  SCOUT  would  be  to  support  a  ground  team’s 
understanding  and  ability  to  perform  anomaly  resolution. 


Potential  Features  of  Interest 


Sotilh  Solar  Airily 
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There  are  myriad  potential  features  of  interest  on  a  large  GEO  spacecraft,  including 
everything  from  solar  array  drive  and  panel  hinges  that  might  become  impaired  due 
to  thermal  issues  or  interaction  with  a  prevalent  environmental  substance,  to  attitude 
determination  sensors  that  may  have  lost  alignment  during  launch  or  are 
experiencing  odd  heating  effects  due  to  an  unforeseen  sun  geometry.  Instances  of 
electric  propulsion  systems  becoming  disabled  on  orbit  is  well  documented,  though 
understanding  of  the  plume  wake’s  interaction  with  the  local  RF  field  is  not. 


Technical  Performance  Metrics 


>lt  is  desired  that  the  visible  imager  be  capable  of: 

•  Resolve  target  with  1  cm  detail  at  100  m  stand-off  4  Focal  Length 
•Sufficient  light-gathering  capability  to  image  target  -4  F-Stop 
•View  the  breadth  of  a  large  GEO  spacecraft  at  a  stand-off  position  of 
less  than  1  km  -4  FOV 

•Fast  imaging  times  -4  CCD  detector  efficiency,  integration  time 
•Mitigate  sensitivity  to  thermal  noise  -4  Peak  wavelength  (pref.  blue) 

>lt  is  desired  that  the  RF  Probe  be  capable  of: 

•Analyze  RF  spectrum  from  1-15  GHz 

•High  resolution  of  discrete  channels  +  Dynamic  range  >  60  dB 
>lt  is  desired  that  the  Laser  Rangefinder  be  capable  of: 
•Determining  stand-off  position  within  1  m  accuracy  at  100-1000  m 
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In  order  to  perform  the  conceptual  design  of  an  Escort  Payload  Module  (EPM),  we 
need  to  reconcile  the  characteristics  of  the  typical  GEO  target  spacecraft  against  the 
Concept  of  Operations  in  order  to  define  some  functional  performance  metrics.  As 
a  consequence  of  this  activity,  it  was  determined  that  a  EPM  consisting  of  a  visual 
camera,  AeroAstro  RF  Probe,  and  a  laser  rangefinder  would  offer  a  balanced, 
diverse  suite  of  inspection  capability.  When  the  high-level  metrics  are  translated  to 
the  EPM  components,  it  is  noted  that  the  SCOUT  vehicle  must  be  able  to  conduct 
its  inspection  and  situational  awareness  activities  at  a  stand-off  position  relative  to 
the  target  that  is  no  closer  than  100  m,  relative  to  center  of  mass.  As  such,  it  is 
desired  that  the  visual  camera  be  capable  of  both  resolving  fine  detail  at  the  nearest 
approach  and  capturing  the  full  extent  of  the  largest  dimension  of  the  satellite  from 
a  relative  location  that  is  less  than  1  km.  As  no  additional  light  source  will  be 
available  for  this  imaging  activity,  the  optics  and  CCD  detector  must  be  sized 
appropriately  to  allow  both  strong  light  gathering  potential  and  short  integration 
times.  Similarly,  the  RF  Probe  must  be  capable  of  analyzing  the  full  spectrum  of 
interest  of  typical  GEO  commercial  and  military  spacecraft  (previously  identified, 
see  chart  3).  With  a  Concept  of  Operations  that  is  predicated  upon  a  nominal 
injection  within  1  km  of  the  target  vehicle  and  a  stand-off  position  no  closer  than 
100  m,  the  EPM  laser  rangefinder  must  be  capable  of  medium  accuracy  across  this 
regime. 


Visual  Camera  Specification 


TT . t|fc 
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Specification 

Value 

Focal  Ratio  (f) 

2.0 

Focal  Length/Aperture 

40  mm  /  20  mm 

Field  of  View  (0) 

5.3° 

Detector  Size 

1004x1004 

Pixel  Size 

7.4  pm  x  7.4  pm 

Pixel  Depth 

10  bits 

Airy  Disk  Diameter 

0.43  pixels  x  0.43  pixels 

Peak  Quantum  Efficiency  (nominal) 

45%  at  490  nm 

Sensitivity  (nominal) 

1 3  p  V/e~ 

CCD  Well  Depth  (nominal) 

60  ke-  (V)  x  120  ke-  (H) 

Total  Camera  Noise 

42  e_  rms 

Based  upon  the  delineated  technical  performance  metrics,  a  visual  camera 
specification  was  defined.  Seeking,  foremost,  the  capability  to  resolve  1  cm  detail 
from  a  relative  stand-off  position  of  100m,  values  for  the  optics  were  determined, 
including  the  focal  ratio,  aperture,  and  effective  field  of  view  (FOV).  The  Basler 
CCD  detector  was  selected  for  its  excellent  sensitivity,  low  camera  noise  floor,  and 
a  peak  quantum  efficiency  centered  about  490  nm — in  the  blue  and  hence  favorable 
for  low  sensitivity  to  thermal  noise. 


Visual  Camera  Performance 


Specification 

Low  Resolution 

High  Resolution 

Distance  to  Target 

536.7  m 

100.0  m 

Size  of  Image  Frame 

50.0  m  x  50.0  m 

9.3  m  x  9.3  m 

Resolution 

49.8  mm  x  49.8  mm 

9.3  mm  x  9.3  mm 

Target  (Soyuz):  2.7m  (Dia)  x  7.9m  (L)  with  9.8m  Wingspan 
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Based  upon  the  optical  specifications  chosen  for  the  desired  resolution  at  nearest 
approach,  in  order  to  view  the  entire  breadth  of  the  largest  spacecraft  dimension 
(taken  to  be  50  m),  the  SCOUT  vehicle  must  regress  to  a  relative  position  of  536.7 
meters.  From  this  vantage  point,  the  imaging  resolution  capability  scales  linearly 
and  is  thus  reduced  to  approximately  50  x  50  mm.  An  example  is  provided  of  the 
Soyuz  spacecraft  that  illustrates  what  the  difference  in  stand-off  position  equates  to 
from  a  visible  perspective. 


Target  Illumination 


|  Eclipse  |  — 

j  06pm 

/ 

; 

12am  /  ^ — 

*  (  Bifo) 

\ 

n 

6am  L_1 

Target 


SCOUT 


>  GEO  target  illuminated 
99.1%  of  annual  orbit 

•  Max  continuous  sun: 
136.0  days 

>  Eclipse  periods  about 
equinoxes: 

•  Max  duration  67.5  min 
♦Min  duration  12.9  min 


DrectionofQbit 


**B3 
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In  order  to  assess  the  ambient  environment  of  a  typical  GEO  spacecraft,  an  Satellite 
Tool  Kit  (STK)  simulation  was  created  and  a  sun  visibility  analysis  was  conducted. 
As  a  result  of  this  effort,  it  was  determined  that  with  the  exception  of  a  few,  brief 
eclipse  periods  that  occur  during  the  equinoxes,  the  featured  spacecraft  is 
illuminated  99.1%  of  the  annual  orbit. 


RF  Probe  Performance 


>  Frequency  Range:  50  kHz  -1 8  GHz 

•  Variable  IF  filter  bandwidth  tuning 

•  Spectral  shape  compared  to  templates 
stored  in  the  MPU 

•  Determine  modulation  type,  date  rate 

•  Emitted  signal  power  (with  stand-off  distance 
known) 

>  Dynamic  range:  80 -100  dB 

•  Linear  channels 

•  Logarithmic  channels 

>  Self-calibration 

>  Ground-controlled  or  semi-autonomous 

>  Interface:  RS-422 

>  Low  power  (6  W) 
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The  AeroAstro  RF  Probe  was  chosen  for  its  specific  capability  to  resolve,  analyze, 
and  define  spectral  signatures  associated  with  broadcast  sources  such  as  those  of 
interest  at  GEO.  The  frequency  range  that  can  be  sampled  by  the  RF  Probe  spans 
that  of  the  identified  spectrum  in  chart  3  with  great  margin.  In  addition,  it  is  capable 
of  reconciling  spectral  characteristics  against  a  known  template  database, 
determining  the  modulation  type  and,  in  conjunction  with  the  laser  rangefinder, 
quantify  the  emitted  signal  power.  Within  the  signal  captured  by  the  RF  Probe,  the 
component  also  features  a  broad  dynamic  range  across  both  linear  and  logarithmic 
channels  that  allows  it  to  separate  individual  channels  of  information.  In  keeping 
with  a  preferred  autonomy  in  the  SCOUT  architecture,  the  RF  Probe  is  capable  of 
self-calibration  and  operation,  though  designed  for  ground-in-the-loop  control. 
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The  laser  rangefinder  (LRF)  was  chosen  for  its  ability  to  resolve  position  with  high 
accuracy,  across  a  broad  range  of  stand-off  positions.  Because  the  Concept  of 
Operations  of  the  SCOUT  Escort  vehicle  specifies  for  an  injection  from  1  km  and  a 
nominal  536  x  284  m  proximity  orbit,  the  long  range  capability  is  essential.  As  a 
power  constrained  microsatellite,  the  LRF  represents  a  small  impact  on  the  overall 
budget. 


The  three  components  are  easily  configured  into  the  nominal  cross-section  footprint, 
stacking  to  a  unit-increment  height  of  8  cm.  Utilizing  an  FPGA  to  both  coordinate 
and  manage  the  devices,  data  output  from  the  visual  camera,  RF  Probe,  and  laser 
rangefinder  are  packetized,  compressed,  and  then  fed  on  to  the  SCOUT  data  bus  via 
the  Core  Electronics  Block.  For  the  visual  camera,  a  motion-jpg  software  layer  is 
included  on  this  processor  in  order  to  compress  both  single  image  and  burst  video 
data  before  being  relayed  to  the  SCOUT  CD&H  system. 


Overview 


>I&T  Philosophy 

>I&T  Flow:  Module  Level 

>SCOUT  Vehicle  Assembly 

> Ground  Integration  and  Test 

>MUGSE  Operations 

>  Launch  Site  l&T  Flow 

> In-Orbit  Test  and  Checkout  Operations 
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One  of  the  best  ways  to  reduce  the  lead-time  and  cost  of  deploying  small  satellites  is 
to  reduce  the  level  of  testing  and  analysis  required  for  launch.  At  this  time,  most 
military  satellites  are  designed  and  built  to  the  very  strict  requirements  of 
MIL-STD-1540  and  MIL-HDBK-343.  While  commercial  and  civil  missions  are  not 
subject  to  the  same,  exacting  standards  for  analyses  and  tests  to  be  performed  prior 
to  a  payload  being  accepted  for  a  launch,  they  still  incur  typical  design  and  AI&T 
programs  that  average  three  years.  In  order  to  leverage  the  responsive  capability 
afforded  by  the  RASCAL  launch  system,  a  vastly  reduced  set  of  testing  and  analysis 
standards  need  to  be  created  for  the  SCOUT  architecture. 

SCOUT  will  utilize  an  AI&T  process  that,  in  much  the  same  way  a  computer 
manufacturer,  does  not  require  complicated  clean-room  procedures,  nor  rely  upon 
custom  equipment  for  different  assemblies  of  components. 


I&T  Flow:  Module  Level 


>  Module  l&T  conducted  by  supplier  (vendor  or  support  facility) 


•Rapid-Ops  Configuration  Field-Checkout 
•Secondary-Manifest  Proto-Qual  Testing  (Mil-Std-1540) 
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Fundamental  to  the  SCOUT  concept  of  AI&T  is  the  implementation  of  open 
architecture  standards  and  robust  interfaces  that  can  support  a  customer  payload 
being  integrated  and  checked  out  at  the  launch  site.  Upon  receipt  of  a  “build”  order 
for  a  specific  SCOUT  vehicle,  a  dynamic  AI&T  process  will  commence. 


The  responsive  nature  of  the  SCOUT  architecture  is  largely  predicated  upon  pre¬ 
qualified  component  modules  that  greatly  reduces  AI&T  schedule.  As  detailed,  all 
qualification  and  acceptance  testing  of  component  modules  is  conducted  by  the 
supplier.  Delivery  to  the  Field  Facility  represents  both  the  vendor’s  certification  of 
manufacturing  and  testing  quality,  with  a  commensurate  acceptance  of  risk  by  the 
customer.  Should  schedule  allow,  proto-qualification  testing  would  be  conducted 
per  Mil-Std-1540. 


SCOUT  Vehicle  Assembly 


> Modules  stacked  from  “bottom-up” 

>  Stack  order  determined  by  configuration 

>  Proposed  order  (bottom-up): 

•  PAF  Interface  module  (PIM)  ||fSj|Lsj 
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At  the  time  of  deployment  order  execution,  the  required  SCOUT  component 
modules  (identified  by  the  MUGSE)  are  layered  from  “bottom-up”  depending  upon 
the  mission-specific  configuration,  typically  beginning  with  the  payload  adaptor 
fairing  (PAF)  interface  module  (PIM),  and  working  up  towards  the  payload 
module(s),  which  complete  the  stack. 


Spacecraft  Integration  &  Test 


>  Master  Universal  Ground 
Support  Equipment  (MUGSE) 

•  Used  in  all  SCOUT  integration 
and  test  activities 

•  Equipped  with  an  easy-to-use 
GUI  for  selecting  tests  and 
interpreting  response  codes 

•  Used  to  upload  and  test  the 
latest  software  and  drivers 

-  Individual  modules 

-  Fully  integrated  spacecraft 

•  Provides  power,  commanding, 
and  both  low-speed  and  high¬ 
speed  telemetry  interfaces 

•  Executes  built-in  test  and 
diagnostic  routines 
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SCOUT  AI&T  will  only  require  use  of  a  portable  Master  Universal  Ground  Support 
Equipment  (MUGSE)  to  provide  all  process  directions  to  technicians  working  in  a 
field-deployable  clean  tent.  The  MUGSE  is  equipped  with  an  easy  to  use  GUI,  bus 
power  supply,  and  connectivity  to  both  the  low-  and  high-speed  bus.  Drivers  and 
configuration  templates  will  be  available  from  a  central,  online  repository  or 
intranet  server,  that  can  be  accessed  by  the  support  technicians  as  needed  to  support 
the  specific  stack  build. 
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MUGSE  Operations 


>  Bus  continuity 

•  High-speed  data 

•  Low-speed  data 

•  Power 

>  Module  checkout 

•  Validate  results  for  Built-In  Test  and  diagnostic  routines 

•  Certify  dictionaries 

-  Command 

-  Telemetry 

•  Functionality 

•  Performance 

>  Stack  configuration 

•  Mass  properties  (e.g.  MOI,  CG) 

•  PID  control  gains,  slew  rates,  pulse  widths 
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Leveraging  the  intelligent,  self-diagnostic  built  in  test  (BIT)  software  that  is 
managed  by  the  MUGSE,  when  communicating  with  the  SCOUT  vehicle  (via  an 
access  port),  technicians  using  the  MUGSE  will  conduct  all  module  interrogation 
and  check-out,  certify  dictionaries  (command  and  telemetry),  perform  overall  stack 
functional  verification,  and  configure  all  mission-specific  software  drivers  and 
parameters  (e.g.  mass  properties  and  PID  control  gains). 


SCOUT  Vehicle  (SV)  Launch  Preparations  &  Launch 


SV  Arrival 
iz)  Launch  Site 


Perform  Post 
Ship  SV 
Functional  Test 


•  Unpack  SV 
•Inspect  hardware 

•  Verify  no  shipping 
damage  to  SV 


SV  Integration 
to  RASCAL  LV 


•  Perform  Pina!  Cleaning 
•Confirm  Expendables 
•Final  Inspection 


•  Rotate  SV  to 
horizontal  position 

•  Lift  SV  and  mate 
with  LV 

•Removal  of  RBF  items 


Launch 

Readiness 

Review 


•  SV  status 

•  LV  readiness 
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Flight 

Readiness 

Review 


*  Review  SV  readiness 
■  Review  test  data 

•  Payload  status 


SCOUT  launch  site  I&T  is  largely  conducted  in  accordance  with  the  specifications 
of  the  RASCAL  or  designated  vehicle,  however,  the  architecture  is  designed  to 
require  minimal  re-touch  and  inspection  once  delivered. 


In-Orbit  Test  Operations 


>  Execute  BIT  and  diagnostic  routines 
> Perform  module  functional  checkout 

>  Verify  Spacecraft  state  of  health  (SOH) 

>  Verify  Spacecraft  configuration 

•  Parameter  and  table  uploads 

> On-Orbit  software  upload  if  necessary 

•  Operators  can  upload  software  patches  or  entire  image  to  S/C 

•  Operator  can  test  uploaded  software  before  committing  to  flash 


rt - - - - - '  - - - 

In-Orbit  Checkout  designed  to  take  less  than  12  hours 
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Another  important  aspect  of  rapid  deployment  is  the  ability  of  the  payload  to 
become  operational  virtually  immediately  upon  reaching  orbit.  This  implies  that  the 
SCOUT  is  active  during  launch,  receiving  time  and  position  data  from  its  GPS 
receiver  and  preparing  to  execute  pre-loaded  commands  upon  separation  from 
RASCAL.  Upon  separation,  the  SCOUT  would  be  able  to  autonomously  de-tumble, 
acquire  attitude,  and  perform  an  functional  state  of  health  (SOH)  check-out  of 
subsystems  via  the  same  BIT  and  diagnostic  routines  executed  during  ground  AI&T. 
Precluding  the  need  or  desire  to  upload  software  patches  or  re-image  the  system,  the 
SCOUT  vehicle  would  commence  normal  operations  and  begin  supplying  data 
according  to  its  operations  plan. 


